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

Re: Incidence of criss-cross merges

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Tue, 17 Jul 2012 15:32:58 +0100 (BST)

Stefan Fuhrmann wrote:
> Julian Foad wrote:
>> At this point, I think the issue boils down to:
>>   * Yes, the criss-cross situation can be produced in plausible real life usage.
>>   * The current handling is sub-optimal, though not worse than we've had before.
>>   * We might want to look at more sophisticated ways to handle it.
>>   * We might want to look at ways to help users avoid the situation.
> The last part has been my concern but I think the following
> policy should work and be feasible in most environments that
> care about qualified merges. Assume we want to update "branch"
> from "trunk" and vice versa.
> * before merging, bring HEAD of branch into a working state
> * catch-up merge from latest known-good rev of "trunk" to "branch"
>   in revision R1
> * consolidate "branch" and bring it to a known-good state
> * merge from latest known-good revision R2 "branch" to "trunk"

So, like this (for those able to read the mail in a fixed-width type face):

       \       \         /
        \       \       /
  branch        R1    R2

> Ensuring R2 > R1 prevents the criss-cross.

Strictly, R2 >= R1.

> R2 does not need
> to be HEAD, i.e. the user may run expensive validation on
> "branch" to qualify it as known-good.


> So, merging from "branch" to "trunk" will become harder and
> there will be fewer such merges. Catching up with "trunk" is
> not affected.

No, the problem is symmetrical: catching up with "trunk" is affected in just the same way as merging back the other way.

There are two ways to enforce such a policy.

  * Using only Subversion mechanisms, a pre-commit hook can reject a commit that would create a criss-crossing merge if committed, as defined above.

  * If we have a working environment that knows when any merge is being performed between these two branches, the tooling could complain if a user starts a merge where the source revision R2 is less than R1 (where R1 is the committed revision of the last merge in the opposite direction) ...

  trunk         R0
       \          \  ___...
        \          \/
         \         /\
          \       /  \
  branch        R2   R1

    ... and also complain if the user starts a merge while a merge in the opposite direction has been
started but not yet committed.

  trunk         R0
       \          \  ___...
        \          \/
         \         /\___...
          \       /
  branch        R2

(I label the source revision of the first merge as "R0" and show it at the same time-position as R2, but in fact it doesn't matter whether R0 is before, at the same revision as or after R2.)

- Julian
Received on 2012-07-17 16:33:35 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.