We think we’ve found a bug in Subversion’s conflict detection during merge operations that results in a false conflict. It occurs after two ‘merge’ commands are committed in reverse order between two branches, and then a subsequent merge is attempted. I’ve attached a repro script that illustrates this problem using svn 1.13.0, and goes at least as far back as svn 1.8.19, on MacOS 10.14.6.
To summarize: 1. Create trunk and branch1 2. Commit an edit to file mu in trunk 3. Commit an edit to file iota in branch1 4. Merge trunk -> branch1 5. Merge branch1 -> trunk 6. Commit trunk 7. Commit branch1 8. Commit further edits to mu in trunk 9. Attempt to merge trunk into branch At step 9, svn appears to have forgotten about the merge from steps 4 and 7 and shows a conflict on mu that has only been edited in trunk. Strangely, the conflict goes away if you flip the order of steps 2 and 3, or commit the merge from step 4 first. While that order of committing merges is typical, this interleaved ordering can arise pretty naturally between two developers working on the same branch. Does this sound like a legit bug? Thanks, Daniel
merge-interleave-3.sh
Description: Binary data
