[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Implicit keep-alive after reintegrate merge

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Mon, 30 Jan 2012 21:38:15 +0100

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".

Received on 2012-01-30 21:39:08 CET

This is an archived mail posted to the Subversion Dev mailing list.