Re: Implicit keep-alive after reintegrate merge

On Mon, Jan 30, 2012 at 11:16 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Jan 30, 2012 at 10:37:51PM +0100, Johan Corveleyn wrote:
>> On Mon, Jan 30, 2012 at 10:19 PM, Stefan Sperling <stsp_at_elego.de> wrote:
>> > 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).
>>
>> No, I don't think it does. The change b_at_r5 doesn't appear in this
>> diff, neither forward nor reversed. Say b_at_r5 adds a line in file b/X,
>> I see no reason this change (forward or reversed) would be part of the
>> difference between b_at_r4 and a_at_r6.
>
> Sorry, I made an error while transferring my experiment into an example.
>
> The problem happens if a non-merge commit (b_at_r4) happens prior to
> the first merge commit (b_at_r5), like this:
>
>                 +b_at_r2---b@r4---b_at_r5--b@r6---b_at_r8--
>       (branch) /               ^             ^ (merge 2)
>               /                | (merge 1)   |
>         --- a_at_r1---a@r3--------+-------a_at_r7--+-------
>
> b_at_r4 appears reversed in 'svn diff b_at_5 a_at_7' -- not good
> a_at_r3 appears in 'svn diff b_at_2 a_at_7' -- not good either, applied twice
> But 'svn merge a_at_r5 a_at_r7' works fine.

Ah yes, I see. Thanks for clarifying.

However, I'm still not convinced :-). I'm starting to think more about
the symmetry with the standard sync-reintegrate cycle. In one of your
previous mails in this thread you described reintegrate like this:

On Mon, Jan 30, 2012 at 2:51 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Mon, Jan 30, 2012 at 02:23:46PM +0100, Stefan Sperling wrote:
>> What we use during --reintegrate is (3.2 b).
>
> And here I'm catching myself spreading misinformation again.
>
> There is another tweak we use during reintegrate.
> Consider the graph again (fixed version):
>
> (3)
> +-b_at_r2--+ b_at_r4--b@r5-b_at_r6 ----
> (branch) / ^ | (merge 2)
> / | (merge 1) v
> --- a_at_r1 ------a_at_r3-----------+- a_at_r7 ----
>
> If we used:
>
> (3.2 b) svn co a_at_r6 wc; svn merge b_at_r4 b_at_r7 a
>
> we'd miss b_at_r2 during the merge. It won't be applied to branch a.
> But we want it in the changeset.
>
> So what really happens is:
>
> (3.2 b) svn co a_at_r6 wc; svn merge a_at_r4 b_at_r6 a
>
> Note that a is compared to b, rather than b against its former self.
> This delta includes b_at_r2 because this change isn't yet on branch a.

So the left argument of the 2-URL merge is
target_at_last-rev-target-was-brought-in-sync (and the right is
source_at_HEAD). That makes sense.

If we translate this to our situation, i.e. the other way around, then
'svn merge b_at_2 a_at_7 b' would be the one. Because b_at_2 is the last time b
was still synced with a. But there is the problem of change a_at_r3 then
being applied twice. However, isn't this the same as the "multiple
reintegrate" problem, i.e. "implicit keep-alive after reintegrate"?

Your example is effectively reintegrating the same "branch" twice.
Which means the same problem applies. And maybe the solution is: we
should be able to skip the already "reintegrated" stuff, i.e. a_at_r3.
(I'm not sure anymore what the state-of-the-art is concerning the
implicit keep-alive stuff, but maybe it's that 'svn diff b_at_2 a_at_7'
needs to be adjusted by subtracting a_at_3 from it, because that's
already been applied)

So I'm guessing that if we can solve the "implicit keepalive after
reintegrate", i.e. let reintegrate skip the already integrated stuff,
we would no longer need --reintegrate, because everything can now be
done with a reintegrate merge.

-- 
Johan