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

[Oswald Buddenhagen]

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
  me)
releases/ (one could call *that* stable/, but that's less descriptive)
other/ - maybe. i don't see much advantage over putting it in trunk/,
  though.
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
trunk/.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.