Hey Paul,
I think that I just found a bug in case-only renames, via merge_tests 105.
When the merge -r2:3 is done into the working copy, there are two
possible outcomes:
GOOD:
2012-04-27 22:21:59 [INFO] --- Merging r3 into
'svn-test-work/working_copies/merge_tests-105/A_COPY':
2012-04-27 22:21:59 [INFO] A
svn-test-work/working_copies/merge_tests-105/A_COPY/MU
2012-04-27 22:21:59 [INFO] D
svn-test-work/working_copies/merge_tests-105/A_COPY/mu
2012-04-27 22:21:59 [INFO] --- Recording mergeinfo for merge of r3
into 'svn-test-work/working_copies/merge_tests-105/A_COPY':
2012-04-27 22:21:59 [INFO] U
svn-test-work/working_copies/merge_tests-105/A_COPY
BAD:
2012-04-27 22:23:27 [INFO] Skipped
'svn-test-work/working_copies/merge_tests-105/A_COPY/MU'
2012-04-27 22:23:27 [INFO] --- Merging r3 into
'svn-test-work/working_copies/merge_tests-105/A_COPY':
2012-04-27 22:23:27 [INFO] D
svn-test-work/working_copies/merge_tests-105/A_COPY/mu
2012-04-27 22:23:27 [INFO] --- Recording mergeinfo for merge of r3
into 'svn-test-work/working_copies/merge_tests-105/A_COPY':
2012-04-27 22:23:27 [INFO] U
svn-test-work/working_copies/merge_tests-105/A_COPY
2012-04-27 22:23:27 [INFO] Summary of conflicts:
2012-04-27 22:23:27 [INFO] Skipped paths: 1
The difference is the order of the editor drive. The "good" form sees
"D mu" first. The "bad form" sees "A MU" first.
I suspect in the bad form, it sees a case-only conflict and decides to
skip the path. Badness ensues.
I've verified this behavior by manually flipping the order of these
two changes during the editor drive.
I don't think there is anything that says we will see deletes first,
followed by adds. It just "happens" to have done that so far. But my
recent work ended up changing that order. Boom.
Any thoughts on what is going on here? Is there some kind of
case-conflict check that causes that skip to happen? (or is it
something else?) ... and the bigger question: how can you get this to
work when the changes arrive as MU-first, mu-second?
Thanks,
-g
Received on 2012-04-28 04:35:50 CEST