subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <p...@hammant.org>
Subject Re: False conflict with interleaved merge commits
Date Fri, 07 Feb 2020 06:52:15 GMT
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@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
>
>
>

Mime
View raw message