On Mon, Jan 30, 2012 at 2:23 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Jan 24, 2012 at 01:12:39AM +0100, Branko Čibej wrote:
>> By the way, I read Stefan's description of why --reintegrate is
>> necessary, and after slogging through the unfortunate terminology (2-URL
>> merge doesn't mean a thing in CM theory :) and one little bit caught my
>> attention:
>>
>> > A sync merge can fill in the all parameters as well, except PATH2.
>> > However, it needs to do so in a different way. With a sync merge
>> > PATH1 and PATH2 are the same
>>
>> I keep reading this in the context of the rest of the reasoning, any my
>> reaction is still: "WTF? Bogus!" This looks like someone /started off/
>> with the assumption that a sync merge can take shortcuts where a
>> reintegrate merge cannot; but, so sorry, that's just plain nonsense.
[ ... ]
> Generally, we want to avoid spurious conflicts from diff3 which happen
> when changes are applied twice because diff3 is not idempotent.
> I.e. we break the nice symmetry to work around a limitation of diff3.
>
> In the following case we can avoid spurious conflicts by picking
> our parameters carefully:
>
> (3)
> +-b_at_r2--+ b_at_r3--b@r4-b_at_r5 ----
> (branch) / ^ | (merge 2)
> / | (merge 1) v
> --- a_at_r1 ------a_at_r2-----------+- a_at_r6 ----
>
> Merge 1 brings a_at_r2 into b_at_r2.
> Merge 2 brings b_at_r4 into a_at_r5.
>
> (3.1) svn co b_at_r2 wc; svn merge a_at_r1 a_at_r2 b
>
> There are two ways of performing merge 2.
> The first is symmetrical and re-applies a_at_r2 to a_at_r6, via b_at_r3,
> with possible spurious conflicts from diff3:
>
> (3.2 a) svn co a_at_r5 wc; svn merge b_at_r2 b_at_r5 a
>
> The second does not re-apply a_at_r2, so there are no possible conflicts
> from diff3 because of a_at_r2/b_at_r3. Only b_at_r4 can conflict.
>
> (3.2 b) svn co a_at_r5 wc; svn merge b_at_r3 b_at_r5 a
>
> The result is the same, however.
>
> What we use during --reintegrate is (3.2 b).
> You can argue that this approach is broken and we should be using (3.2 a)
> for symmetry, and let users deal with spurious conflicts.
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".
--
Johan
Received on 2012-01-30 21:39:08 CET