[Kde-scm-interest] Layout of the Git repositories for KDE (proposal #2)
ossi at kde.org
Mon Nov 5 17:32:45 CET 2007
On Mon, Nov 05, 2007 at 05:00:43PM +0200, Thiago Macieira wrote:
> After realising that we don't have to keep the history of the
> supermodules, I came up with a different idea. Here's it:
now you're coming closer to what i imagined - i.e., something sane. ;-P
there are a few key points to consider:
- *no* repository ever gets moved or deleted once it was created.
anything else is just not going to work, both for current work
with the repos and for reproducing old revisions.
- that basically mandates that everything lives in one directory. to
avoid having 1000+ objects in one directory one could group the
repositories by application category, but *not* by maturity,
supermodule membership, etc.
- higher structure is represented exclusively by supermodules (three
level hierarchy - e.g, kdebase, KDE, everything. some apps might even
opt for a fourth private level to combine several components).
this makes it obvious why a fine granularity is crucial.
the overall structure oriented on your proposal would be like this:
trunk/ (or main/ or master/ or official/ - "stable/" seems just wrong to
releases/ (one could call *that* stable/, but that's less descriptive)
other/ - maybe. i don't see much advantage over putting it in trunk/,
projects/ - here one could relax the "never deleted" rule, assuming
everything here lives inherently outside of official strutures.
every project that wants to branch more than one module creates its
own clones of supermodules, obviously.
users/ - maybe. but why would somebody put something here instead of
"blackhole/" does not exist by definition. it would be a supermodule in
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
Chaos, panic, and disorder - my work here is done.
More information about the Kde-scm-interest