Hi Patrik. 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. - Julian 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 > from. > >> '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. [...]
