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

[Oswald Buddenhagen]

On Mon, Nov 05, 2007 at 07:45:25PM +0200, Thiago Macieira wrote:
> Em Monday 05 November 2007 17:32:45 Oswald Buddenhagen escreveu:
> > 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.
> 
> Where does it break down in the examples I posted?
> 
> I don't like the idea of keeping repositories in "trunk" 4 years after the 
> last commit has been made to it. I do find that moving to unmaintained works 
> best, because it doesn't clutter trunk.
> 
well, it all boils down to the structure being version-controlled. the
supermodules are just git repos with revisions that represent the
logical layout at a given point in time. this breaks down when things
are moved at the file level.
i wouldn't worry about "littering" trunk - nobody but admins is going to
see that anyway, as the canonical access method will be through
supermodules anyway.

> > "blackhole/" does not exist by definition. it would be a supermodule in
> > trunk/.
> 
> Don't agree, see above.
> 
agree now? :)

> > - 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.
> 
> Makes sense, agreed.

> But the moment that you start to categorise, you open the door to
> re-categorisation too. That is, when a new category is added (say,
> "plasma"), some things will want to move because they match better
> (than, say, "base").
> 
hehe. you fell into the trap already: plasma is a technological
category, not an application one, and thus taboo. i'd be more concerned
by kmail turning into a sky exploration application, but i guess we can
ignore this possibility. :-D
anyway, given that "nobody but admins is going to see that anyway", we
can most probably ignore categorisation at the file level.

> > - 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.
> 
> I don't agree with kdebase being a supermodule. I don't know if that's
> what you meant.
> 
it is.
i can only reiterate what i said about three times already: things move
a lot between modules (think the runtime vs. kdelibs re-orga). it is
just impossible to do that Right (TM) if the "major" modules are
monolythic.

remember: as everything is accessed through supermodules usually, nobody
will be bothered by this fine granularity except when he does
administrative work (creating, moving, "deleting" entities) - where it
comes in handy actually (duh!).

> But I agree to the three-level hierarchy:
>
well, i meant three levels of supermodules, so four in total. :)

> > trunk/ (or main/ or master/ or official/ - "stable/" seems just wrong to
> >   me)
> 
> It's a marketing trick to get more people to use it :-)
> 
:-D

> > users/ - maybe. but why would somebody put something here instead of
> >   under projects/?
> 
> Personal back-up and personal projects. [...]
> 
i anticipate a lot of confusion in this area. :)

as far as "crazy idea" projects go, people might want to change the
status of their repo at some point, so they would either move/clone it
around ('cause there's too little to do ...) or leave it
"miscategorized". choose your death.

> Another possibility is to store your own webpages or presentations.
> 
for webpages it sort of makes sense, as it directly maps to the
~/public_html concept. for presentations i'd argue to the contrary -
they should be maintained in a more central "cms". oh, well.

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