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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
