That indeed does appear to be a bug. I filed a new issue to cover it:
I also created a test of a similar scenario that demonstrates the same
problem you found:
If you are feeling ambitious and want to try your hand at fixing this
bug please do -- I'd be happy to review any patches :-) If not, I
should be able to get to this at some point in the near future if
nobody beats me to it.
On Fri, Mar 16, 2012 at 5:37 PM, Jim Paris <jim_at_jtan.com> wrote:
> If I try to reverse-merge the contents of a specific file over a range
> of commits that includes a rename, svn seems to break the commits up
> at the rename and try to reverse-merge in the wrong order.
> svn merge --accept=postpone -r5:1 new
> --- Reverse-merging r3 through r2 into 'new':
> C new
> --- Reverse-merging r5 through r4 into 'new':
> C new
> Summary of conflicts:
> Text conflicts: 2
> There would have been no conflicts if it did "r5 through r4" first,
> then "r3 through r2" second.
> Attached is a script that demonstrates the issue, as well as the
> output of the script on my machine. The last command in the script is
> the one that has the unexpected conflicts.
Received on 2012-03-19 19:42:35 CET