On Fri, Jul 13, 2012 at 7:11 PM, Julian Foad <julianf...@btopenworld.com>wrote:
<snip> > 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: http://www.wandisco.com/subversion/download
