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_ <eic...@thok.org> <eic...@gmail.com>
