[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: Thu, 12 Jul 2012 14:43:47 +0100 (BST)

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.

> 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?

- Julian

> Am I missing something or is that analysis correct? If it is,
> criss-cross issues should be about as common as conflicts
> themselves (depending on the relative size of to-be-merged
> to  not-yet-to-be-merged history).
Received on 2012-07-12 15:44:31 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.