Re: False conflict with interleaved merge commits

On Feb 7, 2020, at 02:44, Stefan Sperling <stsp_at_elego.de> wrote:
>
> On Thu, Feb 06, 2020 at 03:37:10PM -0500, Daniel Dickison wrote:
>> Strangely, the conflict goes away if you flip the order of steps 2 and 3,
>> or commit the merge from step 4 first.
>
> I would say it is working as designed, but the design has its flaws.
>
> As you have found out, the basic problem is that unlike when developers
> work on the same branch, SVN does not enforce an 'svn update' style
> operation when merges and commits interleave.
>
> This is indeed a problem but it is not easy to fix in SVN itself.
> If this happens to your team a lot you might want to let your developers
> know about the issue and show them how to work around it.

Thanks for the detailed info and quick response. This is good to know that it’s a fundamental design issue that’s unlikely to be fixed in SVN itself.

As far as I know, it has only happened for us with a single developer merging between trunk and a branch, and accidentally interleaving the commits. We’ve already put in tooling to block that particular scenario in our wrapper scripts, so hopefully that mostly prevents this from occurring in the wild.

> An easy way to work around it is the following, which essentially
> simulates the missing 'svn update' style step. After a merge, and
> before committing this merge, if the other branch has new changes
> which were not yet merged, merge those changes as follows to "catch up":
>
> svn merge -r0:HEAD ^/the/other/branch

I did not know about this method to force a sync merge. I have a feeling this will come in handy!
Received on 2020-02-07 17:34:34 CET