Here’s a similar one - https://paulhammant.com/2015/10/05/subversion-merge-limitations-not-in-perforce/
On Fri, Feb 7, 2020 at 6:31 AM Daniel Dickison <dan...@bandcamp.com> wrote: > 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 > > >
