On 23.01.2012 18:53, Julian Foad wrote:
> I've committed my latest version of this work to the new 'reintegrate-keep-alive' branch in r1234919.
>
> I'm working on explaining how this stuff relates to ClearCase's model and the need or non-need for a difference between "reintegrate" and "normal" merges in Subversion.
>
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. The
cases are exactly symmetrical, all edge cases apply to both directions
of the merge, a sync merge can encounter all the complications of a
reintegrate merge. I'll be bold enough to assume that the keep-alive
song-and-dance is a direct result of these invalid assumptions.
Well, at least this answers the question of whether it's the model or
the implementation that's wrong ... the answer is, that the
implementation is misinterpreting the model. :)
Just to make sure it's understood: When you create a branch, the origin
of the branch is an interesting bit of information. However, for
merging, it is entirely irrelevant if branch A was created from B or the
other way around. To illustrate:
(1)
+- b_at_r2 ---- b_at_r3 ----
(branch) / | (merge)
/ v
--- a_at_r1 -------------+- a_at_r4 ----
(2)
--- a_at_r1 ----------- a_at_r3 ----
\ | (merge)
(branch) \ v
+- b_at_r2 ------+- b_at_r4 ----
Cases (1) and (2) are exactly equivalent as far as the merge algorithm
is concerned, but Subversion calls the first a reintegrate merge and the
second a sync merge, and treats them differently, as if branch (a) were
somehow special. It's not.
-- Brane
Received on 2012-01-24 01:13:19 CET