On 05/12/2011 04:26 PM, Mark Eichin wrote:
> 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.
It looks like svnrdump needs to implement the revision map concept that
'svnadmin load' implements, mapping revisions as specified in the dumpstream
to revisions in target repository.
> 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.
I'm guessing that this is another bit of fallout from the general problem
that caused your first reported issue.
> 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 :-)
This is just a coding problem. (Probably my own.) I'll see about fixing
this one in the next few minutes.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-05-13 23:14:20 CEST