[Kde-scm-interest] Layout of the Git repositories for KDE (proposal #2)

Oswald Buddenhagen 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
  under projects/?

"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 mailing list