On 30.01.2012 22:19, Stefan Sperling wrote:
> 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)?
The second mege is exactly the same as if the branch were created from
a_at_r3, not a_at_r1. Right? In your example, this is even trivially true,
since there were no changes on the branch between r2 and r4. But given
the slightly more complex example:
+b_at_r2--b@r4-+-b_at_r5---b@r6---+--b_at_r8-----
(branch) / ^ ^ (merge 2) \
/ | (merge 1) | \ (merge 3)
--- a_at_r1---a@r3-----+---------a_at_r7--+-------------+-a_at_r9 ---
the results should be, effectively:
* merge 1:
diff3 b_at_r4 a_at_r1 a_at_r3 | patch b
* merge 2:
diff3 b_at_r6 a_at_r3 a_at_r7 | patch b
* merge 3:
diff3 a_at_r7 b_at_r2 b_at_r4 | patch a
diff3 a_at_r7 b_at_r5 b_at_r6 | patch a
Merge 3 is a cherry-pick merge, of course. But whatever you do, you
always pick your common ancestor so that it's the most recent merge
point from the revision you're merging, and the "myfile" is always the
most recent version on the branch you're merging to (or, effectively, in
the target WC).
You'll be cherry-picking as long as both branches are being actively
modified, but you always have to do the check. The merge algorithm is
symmetric.
Now I don't know how the above merges translate into "svn merge" syntax
and whether or not --reintegrate does it this way, but that's how you do
it manually with diff3. SVN's mergeinfo has all the data that are
required to automate this merging, it's just not being used correctly.
-- Brane
Received on 2012-01-31 01:35:17 CET