[Kde-scm-interest] Layout of Git repositories for KDE

[Johannes Sixt]

I think your proposed layout and policies make a lot of sense. I do have 
concerns about the publically pushable stable repository, but let's give it 
a try.

Thiago Macieira schrieb:
> Legend:
> - ending in ".git" indicates a repository
> - ending in ".git/" indicates a "supermodule" repository -- i.e., 
>    a repository with submodule links. The directory with the same base 
>    name also exists and contains the submodule repositories

Are you talking about the directory layout on the server? I.e. the stuff 
that goes into the URL? Then I suggest the following:

/releases/KDE.git          the supermodule
/releases/KDE/             the directory that contains its submodules
/releases/KDE/kdelibs.git  one of its submodules
...

>   In special, the "www" repository is very ACL-limited to guarantee that 
> the public pages are modified only by trusted people. Do we want to keep 
> that policy? If so, how do we implement it?

Use an update hook that checks the permissions. There is one in git: 
contrib/hooks/update-paranoid

> 4) the "projects" tree is where named projects are undertaken. The layout 
> is not specified. 
>   Named projects are those that have a declared objective. Therefore, they 
> also have a life time: when the goal is reached, the code is merged back 
> into "stable" and the repository is deleted. If the project is abandoned, 
> the code is also merged, but with merge strategy "ours".

Why do this? To keep the history? I don't think that's necessary. If a 
project turns out not to be worth it, why keep it? If it's valuable to 
someone, then that someone can keep a private clone.

> 6) the "blackhole" tree is where dead code is moved to, one repository per 
> unit of code being dropped. Probably with two top-level directories, 3 
> and 4, for organisation purposes.
>   In general, when a full module repository is deprecated, it is simply 
> moved from "stable" with a server-side mv command. If the deprecation is 
> only a subdirectory of a module, I don't really have a recommendation -- 
> it depends on how the "copy-with-history" feature progresses.

You cannot remove any module if it was ever used as a sub-module. The best 
we can do is move it to some "discontinued" hierarchy. "blackhole" in the 
sense of "don't depend on it - it can go away" must not happen, else 
checkouts of older versions that need the submodule are busted.

My suggestion is, therefore, to have a hierarchy "discontinued" inside 
"releases" (for the submodules that were part of a release).

BTW, in order to "deprecate" a subdirectory of a module, you just git-rm it 
and be done with it. The history won't go away.

> 9) note on alternates: repositories in "stable" and "releases" have no 
> alternates. That is, they have full copy of the objects. At most, stable 
> and releases can share hard links.

I don't see the need for a full object database in "stable". What am I 
missing? Why not have alternates pointing to "releases"?

Of course, I'm assuming that "releases" will never rewind branches.

> 11) repositories in "releases" are never deleted nor renamed. This begs 
> the question: what happens if a logical module is renamed or dropped from 
> a release (think kdeaddons, for instance: it is part of KDE 3, but has 
> been removed in KDE 4 in favour of the extragear tree)?

I think it's ok to leave the repository for a while, and move it to 
"discontinued" once the new release (KDE4) is mainstream.

> 12) should repository creation in "stable" and "releases" be done through 
> sysadmins?

Yes. This should be necessary only once in a while.

-- Hannes