[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Implicit keep-alive after reintegrate merge

From: Stefan Sperling <stsp_at_elego.de>
Date: Mon, 30 Jan 2012 22:19:51 +0100

On Mon, Jan 30, 2012 at 09:38:15PM +0100, Johan Corveleyn wrote:
> 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".

Counter-example:

                 +b_at_r2---b@r4---b_at_r5------b@r7-----
       (branch) / ^ ^ (merge 2)
               / | (merge 1) |
         --- a_at_r1---a@r3-+---------a_at_r6--+-------

This performs two "sync" merges from a to b.

The first merge can be done the "reintegrate way":

  svn co b
  svn merge b_at_r2 a_at_r3 b
 
This merge applies the a_at_r3 change to b_at_r2, yielding b_at_r4. Fine.

But how would you perform the second merge, which applies a_at_r6 to
b_at_r5 yielding b_at_r7, using the "reintegrate way", without undoing
b_at_r5 (a non-merge commit)?

You cannot do this:
  svn co b
  svn merge b_at_r2 a_at_r6 b
because this applies the a_at_r3 change again (conflict due to diff3)
since it re-uses the branch point as left anchor for the diff.

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).

The way to specify the diff you want to merge is thus:
  svn co b
  svn merge a_at_r3 a_at_r6 b
Which is what "svn merge ^/trunk" would do.

Maybe there is a flaw and it could be made to work if we somehow
changed the way 'svn merge' operates. But I don't see how.
Received on 2012-01-30 22:20:58 CET

This is an archived mail posted to the Subversion Dev mailing list.