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

[Thiago Macieira]

Em Monday 05 November 2007 09:12:44 Johannes Sixt escreveu:
> 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.

This is what KDE is used to. To change that would mean a disruption in our 
sense of community.

> 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

That's what I meant, though I did not give an example.

My concern, however, is for modules in playground when evolving. If we 
actually *move* the repository, the URL changes and everyone's remotes will 
have to be changed, as well as alternates set up locally and submodules.

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

Yeah, I am afraid of just deleting history. If the project turned out to be 
total crap, then don't keep it. But if it did something useful but proved to 
be ahead of its time or not acceptable, we should merge back so as to not 
lose the changes.

Of course, this is a case-by-case basis. My rationale is that, if the code is 
important enough to have warranted a public repository in a kde.org server, 
then it probably will produce code we don't want to just throw away.

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

Right, that's the meaning of "blackhole" -- discontinued. Your name is better 
actually.

But again you still need to update all supermodules.

That doesn't address the problem of old commits still pointing to the old 
tree. In general, it seems that moving repositories is a bad idea if they've 
ever been a submodule.

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

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

Redundancy and security.

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

See above for submodule issues.

-- 
  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/4dfcf2d3/attachment.pgp