subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Dickison <dan...@bandcamp.com>
Subject Re: False conflict with interleaved merge commits
Date Fri, 07 Feb 2020 16:34:20 GMT
On Feb 7, 2020, at 02:44, Stefan Sperling <stsp@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!


Mime
View raw message