As was reported by Jim Paris <jim_at_jtan.com>
http://svn.haxx.se/dev/archive-2012-03/0343.shtml to the dev list, a reverse
merge that has a rename in the source has the two diffs applied in the wrong order.
For example, say we have a branch 'A' that we copy in r2 to 'A_COPY', make some
edits to in r3-6, rename in r7, make more edits to in r8, then sync merge to
A_COPY, like so:
A--r1--r3--r4--r5--r6--Renamed--r8------------
| To | |
| 'trunk' | |
| r7 | |
copy | reverse
| sync merge
| merge -r9:1
| | |
V V V
A_COPY-------------------------r9-----------X
r2
Currently the merge logic is faulty if we then try to reverse merge the sync
merge. The merge is correctly broken into two editor drives, but the *older*
range is merged first, which can easily result in spurious conflicts:
>svn merge ^^/trunk A_COPY -r9:1 --accept=postpone
--- Reverse-merging r6 through r2 into 'A_COPY':
U A_COPY\B\E\beta
U A_COPY\D\G\rho
C A_COPY\D\H\omega
U A_COPY\D\H\psi
--- Recording mergeinfo for reverse merge of r6 through r2 into 'A_COPY':
U A_COPY
Summary of conflicts:
Text conflicts: 1
..\..\..\subversion\svn\util.c:913: (apr_err=155015)
..\..\..\subversion\libsvn_client\merge.c:10848: (apr_err=155015)
..\..\..\subversion\libsvn_client\merge.c:10812: (apr_err=155015)
..\..\..\subversion\libsvn_client\merge.c:8984: (apr_err=155015)
..\..\..\subversion\libsvn_client\merge.c:4728: (apr_err=155015)
svn: E155015: One or more conflicts were produced while merging r6:1 into
'C:\SVN\src-trunk-4\Debug\subversion\tests\cmdline\svn-test-work\working_copies\merge_tests-127\A_COPY'
-- resolve all conflicts and rerun the merge to apply the remaining unmerged
revisions