On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote:
> No, AFAIU, Brane's suggestion was not that we shouldn't use the
> "reintegrate-way" for 3.2, but rather that we should *always* use the
> "reintegrate-way", also for sync merges. So that a sync merge picks
> its arguments for the 2-URL merge in the same way as a reintegrate
> merge. Unless I misunderstood what Brane meant.
>
> And I think he's got a point. I don't have the time to write up a
> detailed example right now, but I think it should work.
>
> If that would be the case, then we effectively implement the merges
> completely symmetrical: always the "reintegrate-way".
Counter-example:
+b@r2---b@r4---b@r5------b@r7-----
(branch) / ^ ^ (merge 2)
/ | (merge 1) |
--- a@r1---a@r3-+---------a@r6--+-------
This performs two "sync" merges from a to b.
The first merge can be done the "reintegrate way":
svn co b
svn merge b@r2 a@r3 b
This merge applies the a@r3 change to b@r2, yielding b@r4. Fine.
But how would you perform the second merge, which applies a@r6 to
b@r5 yielding b@r7, using the "reintegrate way", without undoing
b@r5 (a non-merge commit)?
You cannot do this:
svn co b
svn merge b@r2 a@r6 b
because this applies the a@r3 change again (conflict due to diff3)
since it re-uses the branch point as left anchor for the diff.
But you cannot use the last-synced revision as left anchor either:
svn co b
svn merge b@r4 a@r6 b
Because applying this delta reverts b@r5 (this change appears reversed
in the diff between b@r4 and a@r6 since it isn't present on branch a).
The way to specify the diff you want to merge is thus:
svn co b
svn merge a@r3 a@r6 b
Which is what "svn merge ^/trunk" would do.
Maybe there is a flaw and it could be made to work if we somehow
changed the way 'svn merge' operates. But I don't see how.
