On Mon, Jan 30, 2012 at 2:23 PM, Stefan Sperling <s...@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@r2--+ b@r3--b@r4-b@r5 ---- > (branch) / ^ | (merge 2) > / | (merge 1) v > --- a@r1 ------a@r2-----------+- a@r6 ---- > > Merge 1 brings a@r2 into b@r2. > Merge 2 brings b@r4 into a@r5. > > (3.1) svn co b@r2 wc; svn merge a@r1 a@r2 b > > There are two ways of performing merge 2. > The first is symmetrical and re-applies a@r2 to a@r6, via b@r3, > with possible spurious conflicts from diff3: > > (3.2 a) svn co a@r5 wc; svn merge b@r2 b@r5 a > > The second does not re-apply a@r2, so there are no possible conflicts > from diff3 because of a@r2/b@r3. Only b@r4 can conflict. > > (3.2 b) svn co a@r5 wc; svn merge b@r3 b@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
