[Kde-scm-interest] Git roadmap

[Oswald Buddenhagen]

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?

> >>   Someone on #git has suggested we import all of SVN into one
> >> monstruous git repository and then work from there, inside git. I
> >> believe, however, we can extract some more metadata from Subversion
> >> (read: file-copy relationships)
> >
> >git does not represent file-copy relationships, so the don't need to be
> >converted.
> 
> 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.

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.

> > The most important information to be recovered are where merges
> > happened. It would be invaluable to represent them in the converted
> > git repository.
> 
> 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.

> 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

> possibly even the svnmerge and svk properties).
> 
... and with svn 1.5, the native props. buuut ... there won't be a whole
lot of such information.


i won't comment on the push patterns, acls, etc., bacause, frankly, i
have no idea what git can do. :}


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.

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.

-- 
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.