I'm working on some svn migration-with-history between repos from
different companies, git-svn isn't cutting it (close, but it loses
properties entirely, and doesn't really give me enough control) so I
thought I'd give svnrdump a try, given that it's been recommended for
this use a bunch of times... built trunk (r1102449, but I don't see
any useful changes in the logs since then) under ubuntu maverick (in a
chroot, with --disable-shared, to avoid contamination from any
ubuntu-supplied subversion libraries.)
I found what appear to be three distinct bugs, demonstrated by the
attached script. The one that actually prompted me to reduce this to
a standalone test script was that snvrdump load failed to handle
renames -- it gave "E160013: File not found: revision 31, path ...",
which I eventually realized was the Node-copyfrom-rev *in the dump*
that it was loading, not the revision the file had actually gotten
loaded into. The only way that could be right is if the two repos
were in perfect sync (and we already have svnsync for that.) The
attached script demonstrates this directly.
The second bug came up while writing the test case: if the destination
repo for the svnrdump load has fewer revisions in it than the source
repo that generated the dump, it blows up *immediately* on the first
revision, with an error number that references the source-dump
revision number. I don't know what it's actually trying to do to that
revision, but it's clear that in the case where the target has more
revs, it's doing whatever that is to the *wrong* rev, and that
deserves investigation. You can demonstrate this by deleting the
"pump the version number up" for loop at line 57 in the attached
script.
The third bug is that "svnrdump -r 3:HEAD" says "E205000: Unsupported
revision specifier used; use only integer values or 'HEAD'" (which is
why the attached script goes out of its way to parse revision numbers
out of "svn info" -- -r 3:7 works fine.) Even if there's a reason to
not support HEAD (though I kind of doubt that) the error message
itself is inconsistent :-)
I haven't looked at the actual code (at this point I may be out of
time and have to go with convincing people that git-svn's
approximation is good enough) but since I'd actually managed to narrow
it down to a clean test case that didn't involve any of the
dump-mangling I'm doing for the actual task, I figured it best to get
that out there so people closer to the code can give it a try.
--
_Mark_ <eichin_at_thok.org> <eichin_at_gmail.com>
Received on 2011-05-12 22:27:22 CEST