Re: False conflict with interleaved merge commits

[Stefan Sperling]

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.

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

Patch for your script:

--- merge-interleave-3.sh   Fri Feb  7 08:19:28 2020
+++ merge-interleave-4.sh   Fri Feb  7 08:29:59 2020
@@ -111,6 +111,7 @@
 ${SVN} merge ${URL}/branches/branch1 wc # Step 5
 ${SVN} pl -v -R wc
 ${SVN} commit wc -m 'Merge branch1 into trunk'  # Step 6
+${SVN} merge -r0:HEAD ${URL}/trunk wcb
 ${SVN} commit wcb -m 'Merge trunk into branch1' # Step 7
 
 # Step 8. edit A/mu one more time in trunk.

Note that I'm using -r0:HEAD to force a "sync merge" at that point.
Once the merge to the other branch has been committed, Subversion will
try to run the 'reintegrate' strategy which will refuse to operate on
a working copy which already contains local modifications.

To understand why your problem is happening, look at the generated mergeinfo.

With your script, the mergeinfo generated by the merge into 'wc' lacks r5:

Properties on 'wcb':
  svn:mergeinfo
/trunk:2-4

Properties on 'wc':
  svn:mergeinfo
/branches/branch1:2-4

As you point out, when merges and commits are done sequentually it works
as expected. Mergeinfo contains this instead:

Properties on 'wcb':
  svn:mergeinfo
/trunk:2-4

Properties on 'wc':
  svn:mergeinfo
/branches/branch1:2-5

r5 is the revision which records the merge from trunk to the branch.
Without r5 in trunk's mergeinfo, 'svn merge' will pick a merge strategy
that includes r5, which includes 'Edit 1'.

Which is why I see no way to fix this in SVN itself.
If we made SVN record r5 during the original merge (before r5 existed),
that would be wrong.
And if we made SVN skip A/mu edits from r5 during the conflicting merge,
that would be wrong, too.

So to me it looks like this needs to be handled by synchronizing
your developers. Sorry :-/


$ svn log -r5 --diff ^/
[...]
Index: branches/branch1/A/mu
===
--- branches/branch1/A/mu   (revision 4)
+++ branches/branch1/A/mu   (revision 5)
@@ -1 +1 @@
-This is the file 'A/mu'.
+Edit 1 of A/mu in trunk
Index: branches/branch1
===
--- branches/branch1(revision 4)
+++ branches/branch1(revision 5)

Property changes on: branches/branch1
___
Added: svn:mergeinfo
## -0,0 +0,1 ##
   Merged /trunk:r2-4

Re: False conflict with interleaved merge commits

[Paul Hammant]

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  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
>
>
>

False conflict with interleaved merge commits

[Daniel Dickison]

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



merge-interleave-3.sh
Description: Binary data

Re: Issues while building subversion-1.10.2 on RHEL6

[Nathan Hartman]

On Thu, Feb 6, 2020 at 1:44 AM Karthik Sonti  wrote:

> Hello Team,
>
>
> I was facing an issue while building subversion-1.10.2 on el6. I'm using
> source from here
> .
> I'm attaching error logs also.
>
> Let me know how to over this issue.
>
> Thanks and Regards,
> Karthik.
>

That is an older release. There have been various bug fixes since then.

Please download the latest 1.10.x release, which is 1.10.6 at this time:

https://subversion.apache.org/download.cgi#supported-releases

If you still have issues with building, let us know...

Thanks,
Nathan