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
