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 <daniel_at_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
>
>
>
Received on 2020-02-07 07:52:32 CET