[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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.

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?


Received on 2020-02-07 07:31:10 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.