[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: Thu, 12 Jul 2012 17:38:37 +0200

On Thu, Jul 12, 2012 at 3:43 PM, Julian Foad <julianfoad_at_btopenworld.com>wrote:

> Stefan Fuhrmann wrote:
> > In Berlin, Julian raised the question how relevant the criss-cross
> > merge case actually. I think I found a reasonable merge policy
> > where those cases become the norm rather than an exception.
> >
> > Most people seem to do what one might call "unqualified" catch-up
> > merges, i.e. "merge everything up to HEAD" regardless of HEAD's
> > state with respect to stability, features, side-effects etc.
> >
> > From a process perspective, it seems much more prudent to
> > do "qualified" merges like "merge from /trunk up to the last
> > fully tested nightly build revision" and "merge from branch up
> > to the point that I think is safe".
>
> Yes, that makes sense.
>
> > In both directions, there will
> > be changes between the catch-up source from A to B and
> > the merge commit form B to A (and vice versa).
>
> I don't quite follow that last sentence.
>

Taking your diagram, I was trying to say that there are revisions
between the qualified / starred revisions and the revisions where
the merges got committed.

> Even if it was
> > the same person doing the merge in both directions, this
> > situation could not be avoided.
>
>
> So, in a bit more detail, the situation is like this:
>
> A = /trunk Tested versions * *
>
> A o---o---o---o---o---o---o---o---o---o---o---o---o
> \ \____ /
>
> \ ____\ __/
>
> \ / \
>
> B o---o---o---o---o---o---o---o---o---o---o
> Safe versions * *
>
> 1 2 3
>
> Sequence of events:
> 1. Nightly testing.
>
> 2. Catch up branch from latest stable trunk.
> 3. Reintegrate branch to trunk, from latest tested version of branch.
>
> That sort of scenario?
>

Exactly. The thing is that at this point the graph does
not even depend on whether the changes to a given
node actually produce a conflict. If the history processing
code had any problems with this kind of merge graph,
that problem would surface more often than actual conflicts.

-- Stefan^2.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2012-07-12 17:39:14 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.