Re: Incidence of criss-cross merges

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

  trunk
    --o-.....-o-.........-o-...
       \       \         /
        \       \       /
         o-.....-o-...-o-......
  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.

Yes.

> 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
    --o-........-o-........
       \          \  ___...
        \          \/
         \         /\
          \       /  \
           o-...-o-..-o-...
  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
    --o-........-o-........
       \          \  ___...
        \          \/
         \         /\___...
          \       /
           o-...-o-........
  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