[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 2-URL merges incorrectly reverse-merge mergeinfo for merge target?

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 19 May 2010 10:47:13 +0200

On Tue, May 18, 2010 at 09:34:37PM -0400, C. Michael Pilato wrote:
> Stefan Sperling wrote:
> > Given the subject line, I guess most of you realised that this mail
> > is intended for Paul and any other merge-tracking nerds on this list :)
> >
> > Attached is a script that shows a merge which removes mergeinfo for
> > the merge target for no explicable reason (at least I can't see a
> > reason for removing it).
>
> The 2-URL merge algorithm determines if the two URLs ("left" and "right")
> are ancestrally related. If so (that is, if there exists a common ancestor
> "ancestor"), merge recording is enabled for the merge. The recorded
> mergeinfo is as follows:
>
> the reverse-merge of the diff between "ancestor" and "left"
> + the merge of the diff between "ancestor" and "right"
>
> So let's start with: "Does this match what you see in your scenario?"
> (I've not yet read your extensive script or its output yet.)
>
> From there, we can move on to: "Is this expected-but-still-braindead?"

I've tried to follow my example based on your assumption about
Subversion's behaviour. I think I found that Subversion does
not do what you describe. So the answer would be "No, this does
not match what I see in my scenario."

Take a couple of minutes and bear with me.
Here's what happens in my example:

r6 creates the feature1 branch:

  ------------------------------------------------------------------------
  r6 | stsp | 2010-05-19 09:51:05 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     A /branches/feature1 (from /trunk:5)
  
  create feature1 branch
  
r7 does original work on feature1:

  ------------------------------------------------------------------------
  r7 | stsp | 2010-05-19 09:51:05 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     M /branches/feature1/beta
  
  work on feature1
  
  Index: branches/feature1/beta
  ===================================================================
  --- branches/feature1/beta (revision 6)
  +++ branches/feature1/beta (revision 7)
  @@ -1 +1,2 @@
   beta
  +bbb

r10 creates the feature2 branch:

  ------------------------------------------------------------------------
  r10 | stsp | 2010-05-19 09:51:06 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     A /branches/feature2 (from /trunk:9)
  
  create feature2 branch
  
r11 does original work on feature2:

  ------------------------------------------------------------------------
  r11 | stsp | 2010-05-19 09:51:06 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     M /branches/feature2/alpha
  
  work on feature2
  
  Index: branches/feature2/alpha
  ===================================================================
  --- branches/feature2/alpha (revision 10)
  +++ branches/feature2/alpha (revision 11)
  @@ -1,2 +1,3 @@
   alpha
   aaa
  +aaaa

r12 reintegrates this work into trunk:

  ------------------------------------------------------------------------
  r12 | stsp | 2010-05-19 09:51:07 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     M /trunk
     M /trunk/alpha
  
  reintegrate from feature2 branch
  
  Index: trunk/alpha
  ===================================================================
  --- trunk/alpha (revision 11)
  +++ trunk/alpha (revision 12)
  @@ -1,2 +1,3 @@
   alpha
   aaa
  +aaaa
  
  Property changes on: trunk
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Merged /branches/feature2:r10-11

r13 blocks the reingration revision so we can continue
to use the feature2 branch and reintegrate it again later:

  ------------------------------------------------------------------------
  r13 | stsp | 2010-05-19 09:51:07 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     M /branches/feature2
  
  block reintegration revision
  
  
  Property changes on: branches/feature2
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Merged /trunk:r12

r14 syncs feature2 with the trunk:

  ------------------------------------------------------------------------
  r14 | stsp | 2010-05-19 09:51:08 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     M /branches/feature2
  
  sync with trunk
  
  
  Property changes on: branches/feature2
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Merged /trunk:r10-11,13
  
We can see that r12 was correctly skipped during the merge.

In r15, feature1 is synced with trunk, which brings the r12 state
of feature2 work into feature1:

  ------------------------------------------------------------------------
  r15 | stsp | 2010-05-19 09:51:08 +0200 (Wed, 19 May 2010) | 1 line
  Changed paths:
     M /branches/feature1
     M /branches/feature1/alpha
  
  sync with trunk
  
  Index: branches/feature1/alpha
  ===================================================================
  --- branches/feature1/alpha (revision 14)
  +++ branches/feature1/alpha (revision 15)
  @@ -1,2 +1,3 @@
   alpha
   aaa
  +aaaa
  
  Property changes on: branches/feature1
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Merged /branches/feature2:r10-11
     Merged /trunk:r9-14

Here's a small graph of the above, omitting the merge done in r13
since it was only done so that the merge in r14 would succeed:

feature1 +--r7---------------------+--
        /r6 /r15
trunk -+------+----------+--+----+----
               \r10 /r12 \r14
      feature2 +--r11-+------+-------

At this point, we have the following mergeinfo (I replaced the repos
URL with ^/):

Properties on '^/branches/feature1':
  svn:mergeinfo
    /branches/feature2:10-11
    /branches/firstbranch:2-3
    /trunk:6-14
Properties on '^/branches/feature2':
  svn:mergeinfo
    /branches/firstbranch:2-3
    /trunk:10-13
Properties on '^/trunk':
  svn:mergeinfo
    /branches/feature2:10-11
    /branches/firstbranch:2-3

We see mergeinfo for "firstbranch". This is a historic branch
which was merged into trunk and delete before feature1 and feature2 existed.
I didn't mention it so far, and I don't think it's relevant.

We now do the following merge into a working copy of feature2:

  svn merge ^/trunk_at_15 ^/branches/feature1_at_HEAD (HEAD happens to be 15)

This brings the original work done on feature1 into feature2,
originally committed in r7:

  Index: beta
  ===================================================================
  --- beta (revision 15)
  +++ beta (working copy)
  @@ -1 +1,2 @@
   beta
  +bbb

But it nukes the mergeinfo for trunk from feature2:

  Property changes on: .
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Reverse-merged /trunk:r10-13
     Merged /branches/feature1:r6-15

If we commit this, feature2 loses important mergeinfo.
It looks as if we had never merged from trunk into feature2, which is wrong.
Revisions r10 to r16 are merged from trunk to feature2 again upon the
next sync merge (the merge only changes mergeinfo in this example,
but in reality this can cause conflicts to occur again):

  $ svn ci -m "commit merge result"
  Sending .
  Sending beta
  Transmitting file data .
  Committed revision 16.
  $ svn up
  At revision 16.
  $ svn merge ^/trunk
  --- Merging r10 through r16 into '.':
   G .
  --- Recording mergeinfo for merge of r10 through r16 into '.':
   U .
  $ svn diff
  
  Property changes on: .
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Merged /trunk:r10-16

You said the algorithm was:

     the reverse-merge of the diff between "ancestor" and "left"
   + the merge of the diff between "ancestor" and "right"

Unless I'm mistaken, in this case ancestor is trunk_at_6,
left is trunk_at_15, and right is feature1_at_15.

The mergeinfo diffs are as follows (omitting other changes svn diff prints):

  $ svn diff ^/trunk_at_15 ^/trunk_at_6
  Property changes on: .
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Reverse-merged /branches/feature2:r10-11

The first mergeinfo diff reverts mergeinfo created on trunk during
the reintegration of feature2. I'm not sure if our plan of applying
this mergeinfo diff to feature2 is correct, but since reverse-merging
from natural history does not create mergeinfo and we do not actually
revert r10 and r11, this change is probably inoperative.
  
  $ svn diff ^/trunk_at_15 ^/branches/feature1_at_15
  Property changes on: .
  ___________________________________________________________________
  Modified: svn:mergeinfo
     Merged /trunk:r6-14

The second mergeinfo diff looks correct, and is a superset of the
current trunk mergeinfo on feature2 (/trunk:10-13).
So I'd expect the following mergeinfo on feature2 after the merge:

  Properties on '^/branches/feature2':
    svn:mergeinfo
      /branches/firstbranch:2-3
      /trunk:6-14

Which is evidently not what is happening.
So is this a bug?

Stefan
Received on 2010-05-19 10:47:54 CEST

This is an archived mail posted to the Subversion Dev mailing list.