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_at_r2---b@r4---b_at_r5------b@r7-----
(branch) / ^ ^ (merge 2)
/ | (merge 1) |
--- a_at_r1---a@r3-+---------a_at_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_at_r2 a_at_r3 b
This merge applies the a_at_r3 change to b_at_r2, yielding b_at_r4. Fine.
But how would you perform the second merge, which applies a_at_r6 to
b_at_r5 yielding b_at_r7, using the "reintegrate way", without undoing
b_at_r5 (a non-merge commit)?
You cannot do this:
svn co b
svn merge b_at_r2 a_at_r6 b
because this applies the a_at_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_at_r4 a_at_r6 b
Because applying this delta reverts b_at_r5 (this change appears reversed
in the diff between b_at_r4 and a_at_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_at_r3 a_at_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.
Received on 2012-01-30 22:20:58 CET