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@r2 ---- b@r3 ---- (branch) / | (merge) / v --- a@r1 -------------+- a@r4 ---- (2) --- a@r1 ----------- a@r3 ---- \ | (merge) (branch) \ v +- b@r2 ------+- b@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