On Mon, Jan 30, 2012 at 11:16 PM, Stefan Sperling <s...@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 <s...@elego.de> wrote: >> > But you cannot use the last-synced revision as left anchor either: >> > svn co b >> > svn merge b@r4 a@r6 b >> > Because applying this delta reverts b@r5 (this change appears reversed >> > in the diff between b@r4 and a@r6 since it isn't present on branch a). >> >> No, I don't think it does. The change b@r5 doesn't appear in this >> diff, neither forward nor reversed. Say b@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@r4 and a@r6. > > Sorry, I made an error while transferring my experiment into an example. > > The problem happens if a non-merge commit (b@r4) happens prior to > the first merge commit (b@r5), like this: > > +b@r2---b@r4---b@r5--b@r6---b@r8-- > (branch) / ^ ^ (merge 2) > / | (merge 1) | > --- a@r1---a@r3--------+-------a@r7--+------- > > b@r4 appears reversed in 'svn diff b@5 a@7' -- not good > a@r3 appears in 'svn diff b@2 a@7' -- not good either, applied twice > But 'svn merge a@r5 a@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 <s...@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@r2--+ b@r4--b@r5-b@r6 ---- > (branch) / ^ | (merge 2) > / | (merge 1) v > --- a@r1 ------a@r3-----------+- a@r7 ---- > > If we used: > > (3.2 b) svn co a@r6 wc; svn merge b@r4 b@r7 a > > we'd miss b@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@r6 wc; svn merge a@r4 b@r6 a > > Note that a is compared to b, rather than b against its former self. > This delta includes b@r2 because this change isn't yet on branch a. So the left argument of the 2-URL merge is target@last-rev-target-was-brought-in-sync (and the right is source@HEAD). That makes sense. If we translate this to our situation, i.e. the other way around, then 'svn merge b@2 a@7 b' would be the one. Because b@2 is the last time b was still synced with a. But there is the problem of change a@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@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@2 a@7' needs to be adjusted by subtracting a@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
