False conflict with interleaved merge commits
From: Daniel Dickison <daniel_at_bandcamp.com>
Date: Thu, 6 Feb 2020 15:37:10 -0500
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.
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?
This is an archived mail posted to the Subversion Users mailing list.