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

[Thiago Macieira]

Em Monday 05 November 2007 13:49:01 Johannes Sixt escreveu:
> Thiago Macieira schrieb:
> > 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.
>
> But only people who actually had the module checked out are affected. Only
> after the module went into /stable many more people would be affected. This
> means that there better be good plans where to put the module before it
> goes to /stable.

Playground was part of /stable in my proposal.

I guess we could merge playground with projects. New applications being 
created are a "project" and they get moved directly into stable/kdereview 
when they are considered stable. Thus we merge also the concepts of stable 
and release-worthy.

The drawback is that people will have no incentive to check out playground and 
try to build it. I do this right now and try to fix things here and there. 
Or, rather, did that in KDE 3. It's a mess right now.

> >>> 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.
>
> Then using strategy "ours" is the wrong thing to do. This basically *hides*
> all the changes that are merged in, and it becomes impossible to merge them
> again (without playing games) if they later turn out to be valuable.

Hmm... I see. I had asked this question in the #git channel and merge -s ours 
was the reply I got.

The question was: what happens to a branch that you don't want to merge the 
changes back into the mainline? In Subversion, we simply delete the branch 
because we know the changes aren't lost, though it is difficult to find them 
again (you must know the branch URL and search when it was deleted). This is 
actually the reason why we introduced tags/unmaintained/.

I guess we can simply extend the concept to the new discontinued/ tree: we 
have a copy of any module there, with branches pointing to discontinued 
branches.

> The better option is to move the history to a branch (possibly read-only)
> in the /stable hierarchy.

I'd rather not clutter /stable with unnecessary branches or repositories.

I think organisation has to be thought of very early in the process to avoid 
this:
http://git.kernel.org/

There's at least a hundred linux/kernel/git repositories. It's easy to get 
lost.

> > 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.
>
> Basically, yes. But the location can be tuned locally (in the config file),
> so after a really long grace period it is still "safe" to move a submodule:
> Anyone who has some incentive to checkout a really old version can fix the
> location.

That doesn't help checking out KDE 1 or 2. Granted, you probably cannot even 
build them anymore with a recent C++ compiler, but it's nice to be able to 
get the exact release.

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