On Feb 7, 2020, at 02:44, Stefan Sperling <s...@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!
