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 ^/tr...@15 ^/branches/featu...@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 tr...@6,
left is tr...@15, and right is featu...@15.
The mergeinfo diffs are as follows (omitting other changes svn diff prints):
$ svn diff ^/tr...@15 ^/tr...@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 ^/tr...@15 ^/branches/featu...@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
