[Kde-scm-interest] meeting summary

[Thiago Macieira]

Em Quinta-feira 10. Dezembro 2009, às 00.03.14, Oswald Buddenhagen escreveu:
> > svn2git import rules: a bit of confusion over whether morice is going
> > to be working on this (but he was doing hook stuff this week anyways).
> > tz says sho_ might be willing to help. morice will try it.
> > 
> 
> it's still beyond me what the deal about that is ... did anybody
> actually try to fix the script to follow project moves and branches in
> svn instead of doing everything by hand? 

No. First of all, it's not a script. svn2git is a complex program written in 
C++, using libsvn_fs-1, libsvn_repo-1 and QtCore.

Second, I think that would be extremely complex. Take for example, when KDE is 
branched, we copy trunk/KDE to branches/KDE/x.y. That's all the information 
there is in Subversion. However, the repositories are one level deeper than 
that (and in your proposal, two levels).

This matches the "action recurse" in the current rules, telling svn2git that 
it needs to go into the directory, reconstruct the copied-from paths and try 
to apply the next rules.

So, maybe we can change it to always recurse if we copied a dir that didn't 
match any rules and see if we ended up creating a branch.

Ok, so far so good. But I don't have good algorithms for:

1) detecting moving of the "master" branch. That is, 
	trunk/kdelibs -> trunk/KDE/kdelibs
	trunk/playground/foo/bar -> trunk/kdereview/bar -> trunk/extragear/foo/bar
	trunk/kdenonbeta/bar -> trunk/KDE/foo/bar

2) detecting project renaming. That is,
	trunk/playground/foo/bar -> trunk/playground/foo/baz
	(maybe: if the "master" branch seems to be copied to the "master" branch of 
	another repository)

3) correcting improper branching. Things like,
	trunk/KDE/kdelibs -> branches/kde4/kdelibs -> trunk/KDE/kdelibs
	while trunk/KDE/kdelibs -> branches/KDE/3.5/kdelibs

	the whole branches/stable/stuff which is extremely hard for the tool

4) detecting non-standard projects. Things like,
	trunk/playground/base/plasma-addons/foo

5) skipping silly mistakes, like,
	trunk/playground/foo/project/KDE/kdelibs
	trunk/playground/foo/project/KDE/kdebase
	[...]

> did anyone try git-svn with
> proper options as an alternative (just to see whether it's wouldn't be a
> better start at this point)?

Yes, I tried, about two years ago. It has two problems: one, it's far, far too 
slow. I gave up after 48 hours running when it had reached only revision 320k 
in SVN. I estimate that git-svn would run for at least 4 days *per* 
*repository*. We have 450+ repositories in my rules -- in yours, we'd easily 
double that.

The second reason is that it had no way of tracking moves of the "master" 
branch. Not when I tried, anyway. Maybe it does so now. But to detect a trunk 
move, we go back to problem #1 above, which I think requires doing two sweeps 
of the SVN history: the first one backwards, starting from the current 
location, finding out where it came from, then the second one forwards, doing 
the import.

Maybe what we can learn from this is we can have a "rule-writing" script that 
scans our history backwards, given a seed of information (where our current 
repositories' branches are).

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
      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: 190 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20091210/7854d1b1/attachment.sig