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

[Johannes Sixt]

Thiago Macieira schrieb:
> After realising that we don't have to keep the history of the supermodules, I 
> came up with a different idea. Here's it:

Of course, you need to track the history of supermodules. How else would you 
handle atomic cross-module commits?

> meta/
>   all.git  -- matches subversion's trunk
>   kdesupport.git
>   KDE.git
>   kdereview.git
>   extragear.git
>   extragear-libs.git
>   extragear-base.git
>   extragear-multimedia.git
>   extragear-network.git
>   playground-libs.git
>   playground-base.git
>   playground-nonkde.git
>   [...]

If there are two parallel structures, release/ and devel/, then you cannot 
get away with a single distribution point for the supermodules. At the 
least, release/KDE.git is needed. [And, technically, that's the only module 
that needs a tag like KDE_4_2, because that commit implies the commits in 
the submodules.]

But then you also needed stable/KDE.git. Think of a cross-module change:

* I change some API in kdelibs.
* Then I need to update kdebase, etc.
* In order to make the change atomic, I must make a commit in KDE.git that 
includes *my* new states of kdelibs, kdebase, etc.
* I must make this commit available to others, else they see inconsistencies.
* Where do I do that? stable/KDE.git is the only reasonable place.

> The idea here is that stable/ is a *flat* tree with repositories. It can be a 
> list as long as http://git.kernel.org. It doesn't really matter. Technically, 
> the same layout of stable/ could be applied to releases/.
> 
> The important thing is that the organisation of KDE is reflected in the meta 
> repositories -- i.e, the supermodules. We'd expect people to check out the 
> meta repositories if they're interested in building KDE in general. If they 
> are contributors to one or just a few modules, they can check out what they 
> want exactly.

You are of course right here.

I still suggest to reflect the (logical) module hierarchy also in the 
(physical) server layout. Simplicity is my only argument, though ;)

-- Hannes