[Kde-scm-interest] Git roadmap

[Thiago Macieira]

On Tuesday 18 September 2007 10:22:31 Oswald Buddenhagen wrote:
> On Tue, Sep 18, 2007 at 09:27:19AM +0200, Thiago Macieira wrote:
> > Another issue is the use of svn:externals. [...]
>
> hmm, does git version fs metadata (directories, permissions, symlinks)
> at all?

Symlinks are special entries in the git tree. So, they are handled like any 
other file.

Directories are "versioned" in the sense that git keeps track of them and 
erases once they are empty. But empty directories are not supported. Add 
a .gitignore file there if you want to keep it.

The only permissions that are kept are the execute bits. That is, git knows 
the difference between 644 and 755. But it does not know 664 or 666. That 
doesn't make sense for a version-control system. The actual permissions are 
taken by the umask -- you can have a "private" repository of your own, inside 
your home, or you can have a public one where other users in the host can 
commit to.

> > Unfortunately, they have. It's the copy across modules, like I said
> > above.
>
> exactly. this is the reason why we should have per-app/lib repos.
> kdelibs is no exception. organization would be done by two levels of
> meta-repos.
> this also solves the problem of partial tags/branches.
> the trunk move would be basically just a special case of a module move.

Not sure I agree. It doesn't solve completely the problem of 
copy-across-modules. In fact, the more modules you have, the worse this 
problem is: we did a lot of moves between kdecore - kdeui - kio in the past 
year, probably as many as we did between kdelibs and kdebase/runtime.

> finer grained moves across modules should leave a log entry with an url
> that can be directly followed to the old location. replaying history or
> something would be nonsense, and it wouldn't work in later day-to-day
> use anyway.

Hmm... you're saying "when we move, ignore old history but add a note where it 
came from". This goes back to what we had with CVS without server-side moves. 
It's a loss in functionality I'd like to avoid if we can.

> > These, I think, can be done manually. I.e., after converting to git,
> > we can use grafts to mark the commits that were merges and then do a
> > single, major filter-branch to make the grafts permanent.
>
> anything manual isn't going to work really. it could be done for the
> currently active branches, but that's a bit too little, imho.

Indeed. Since SVN doesn't mark those merges anyways and we're doing just fine 
without them, there's no problem not marking those merges in git. We can't 
lose what we don't have anyways.

The problem I see is that in SVN you can erase a branch and it isn't lost. In 
git, if you erase a branch, there will be unreachable commits that will be 
erased the next time git-gc is run. So we'd need to either "close" those 
branches by doing merge into the mainline or we'd need to keep "dead 
branches" somewhere.

> > Subversion does not record that information, so we can't extract that
> > information from it. It can be automated somewhat, though.
> >
> > (Heuristic matching the commit log messages,
>
> anything based on log messages would be way too fragile.
> but comparing chunks from the deltas isn't that hard in principle. have
> fun. :-D

True. The only merges I'm worried about are those that "close" a branch: i.e., 
when you merge your branch's changes into another branch. See above.

Any other merges are probably not real merges in the git sense of the word.

> on a related note ... our cvs2svn conversion still needs to be fixed
> before we convert it again. you might remember that we had a lot of
> missing files on branches. coolo fixed this for the currently active
> branches, but the rest of the history is still screwed up completely.
> the plan is to re-convert with a current version of cvs2svn and
> retro-fit it into the existing repository. coolo agreed in principle,
> but it would be quite a project to actually do it.

What I've heard is that a CVS to git conversion generally benefits by an 
intermediary step of going through SVN. But I've also heard that a "git 
output" mode for cvs2svn would be interesting. I have no idea if it's in the 
works.

But if we do the conversion to git, it sounds like the perfect time to run 
cvs2svn again.

As a side-note, the server-side moves we did in CVS time would probably be ok 
when represented in git.

> yet another related note on the conversion: cvs2svn "evened out" a lot
> of ugly parts from the history (non-atomic commits in particular, and we
> deleted some dead imports, etc.). now ... there is a helluva lot of
> abuse of svn now, and it is even more apparent than in cvs times. so we
> might want to merge non-atomic commits again, detect client-side module
> moves, etc.

-- 
  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/20070918/1850f366/attachment-0001.pgp