Just to let you know, I have not started on this issue yet, but have still got this flagged for attention and have been sorting out other dump/load issues which hopefully will make this one easier to address.
If necessary (if I don't get to it soon) I'll file an issue to track it so it doesn't get forgotten.
Patrik Jonsson wrote:
> Hi Julian,
> Thanks for responding.
> On Thu, Jan 15, 2015 at 12:55 AM, Julian Foad wrote:
> I'm using 1.7.19. The server that generated the initial dumpfile is
> still running 1.6, I believe, if that matters.
> I tried using svndumpfilter, but there has been enough copying back
> and forth during the history of the repo that recursively including
> all those paths became untenable. Instead, I used
> https://github.com/jasperlee108/svndumpfilterIN, which uses svnlook to
> copy the content of an out-of-path copyfrom when it finds one.
> However, it doesn't do any renumbering of the revs, so if
> svndumpfilter does that, that's probably where my problem (1) comes
>> 'svndumpfilter' and 'svnadmin load' are both supposed to
>> adjust revision number references in both copyfrom and mergeinfo. However, I
>> have looked at the code and it doesn't look robust.
> I can definitely say that 'svnadmin load' choked when it got to the
> first copyfrom with a nonexistent rev. I haven't look that carefully
> at the code, but it seemed to me that it was only doing renumbering
> due to differing start revs in the dump and the repo, not fixing
> "holes" in the numbering.
Received on 2015-01-26 21:11:04 CET