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

[Thiago Macieira]

Em Monday 05 November 2007 19:21:13 Oswald Buddenhagen escreveu:
> > 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.

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...

> > > - 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.

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.

The only *current* solution for file moves anywhere is what we adopted with 
Subversion: one huge repository.

The way I see it, the proper solution is for copy-with-history to work across 
modules.

> 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.

> > > 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?

This is only natural with git: everyone should have their own private 
repositories. Some people can afford a webserver online 24/7 to host that. 
Most people can't.

> 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.

Create a new repo in the appropriate area (projects or stable) and push into 
it.

> > 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.

Maybe you're right. My presentations in TeX (beamer) feel like revision 
control, though :-)

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20071105/1dd011e9/attachment.pgp