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

[Oswald Buddenhagen]

On Mon, Nov 05, 2007 at 10:39:50PM +0200, Thiago Macieira wrote:
> Em Monday 05 November 2007 19:21:13 Oswald Buddenhagen escreveu:
> > categorisation at the file level.
> 
> I was thinking of the subdirs of extragear and playground. Originally, they 
> were well-defined:
> 
> 	libs
> 	base
> 	network
> 	multimedia
> 	office
> 	etc.
> 
> But extragear/plasma is now there...
> 
"base" is too wishy-washy. "plasma" outright sucks. i guess they would be
mostly "desktop" or something like that. libs ... prolly not - they
either belong to some specific category or are, duh, base. heh.
anyway, i postulated that we probably don't need to think about this. :)

> > 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.
> 
> And it's still impossible to do it if we break at the
> library/application level. We have files/classes moving between
> libraries. If we do break at the library level, then those -- that are
> currently handled -- start not to be handled.
> 
yes, obviously this is a no-win situation. still, i'd opt for the proper
thing for "natural" units - that's the recommended git usage anyway -
and fall back to more hacky solutions (history replay) for cases where
even finer granularity is needed.

> > 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!).
> 
> Except submodules don't behave like that. Like I said in another email: I 
> don't recommend git-submodule for our current modules unless using them 
> *feels* like one single repository. Right now, git diff doesn't show changes 
> in sibling modules, git annotate will not cross repository borders for moves, 
> etc.
> 
well, that just means that submodule handling needs to improve
drastically. luckily, "they" still have > 1 year. :)

> > > > 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. :)
> 
> Do you know we have branches/work/~dang, ~vkrause, ~wstephens in Subversion 
> already?
> 
yes. i see no problem with having them lumped together with projects in
one work/ directory, though. this naming is pretty arbitrary anyway.

hmm, how would we proceed in the conversion? i guess everything goes to
master/ and releases/ initially? or have a map file to extract certain
branches to projects/, i.e. practically dispose of them?

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