subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dickison <>
Subject False conflict with interleaved merge commits
Date Thu, 06 Feb 2020 20:37:10 GMT
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?


View raw message