Hi Julian, Thanks for keeping me in the loop. The workaround with +1/-1 when getting the mapping rev seems to work for now.
/Patrik On Mon, Jan 26, 2015 at 10:09 AM, Julian Foad <julianf...@btopenworld.com> wrote: > 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. > [...] >
