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
<julianfoad_at_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.
> [...]
>
Received on 2015-01-26 21:11:30 CET