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@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)?
The second mege is exactly the same as if the branch were created from
a@r3, not a@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@r2--b@r4-+-b@r5---b@r6---+--b@r8-----
(branch) / ^ ^ (merge 2) \
/ | (merge 1) | \ (merge 3)
--- a@r1---a@r3-----+---------a@r7--+-------------+-a@r9 ---
the results should be, effectively:
* merge 1:
diff3 b@r4 a@r1 a@r3 | patch b
* merge 2:
diff3 b@r6 a@r3 a@r7 | patch b
* merge 3:
diff3 a@r7 b@r2 b@r4 | patch a
diff3 a@r7 b@r5 b@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
