[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: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Tue, 17 Jul 2012 10:44:52 +0200

On Fri, Jul 13, 2012 at 7:11 PM, Julian Foad <julianfoad_at_btopenworld.com>wrote:


> As far as I have been able to discover, there is no generally agreed
> solution to the problem. Most of the references I can find are, like [3],
> a commentary on one or more of the attempts that have been made to find a
> better solution. I found one summary [2] of how different merge algorithms
> attempt to handle the criss-cross scenario. It is a bit too light on
> detail, but it does mention some interesting solutions and their
> limitations.
> 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"

Ensuring R2 > R1 prevents the criss-cross. 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.

-- Stefan^2.

Certified & Supported Apache Subversion Downloads:
Received on 2012-07-17 10:45:26 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.