[MERGE] Allow external annotation tie breakers

John Arbash Meinel john at arbash-meinel.com
Mon Mar 30 15:08:12 BST 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
> We currently use alphabetical sort to break ties between
> annotations when line content is identical.
> 
> This is arbitrary but with a constraint which is to provide
> stability against further merges (otherwise we may flip-flop the
> attribution if criss-cross merges occur).
> 
> It happens that using the oldest revision better fits user
> expectations in most of the cases.
> 
> We can't (with the current design) easily determine which
> revision is the oldest.
> 
> Yet, this patch introduce a specific function that plugins can
> override until we provide a better solution.
> 
>          Vincent
> 

So it isn't so much about 'criss-cross' as just regular merging. As a
pretty graph:

  A
  |\
  B C # both introduce the same content
  |X|
  D E # Actual criss-cross
  |/|
  F | # simple merge
   \|
    G # simple merge

We've proposed 3 possible resolution schemes, 'left', 'right' and
'sorted'. I'll outline the results they give.

Obviously in B & C both revisions will claim themselves as the
annotation parent for any of the schemes.

If you look at D (B merging C), we will notice that the annotation
differs, and then do a heads() check, and find that both are considered
heads.
  'left'  will stick with its primary parent, and continue to say 'B'
  'right' will go with the merge parent, and say 'C'
  'sorted' will go with the lexicographically lowest (B).

However, you can do the same comparison at E
  left	 C
  right  B
  sorted B

So the problem comes in, when you go to merge into F. At this point, if
you use left or right, the annotations will still differ ('left' keeps
their differences, 'right' swaps them). However 'sorted' now agrees, so
there is no further resolution.

So for F the results are:
  left	B
  right	B (E has B from the previous merge, so supersedes C)

Then when you come to G, if you picked 'right' you have now converged,
because F and E both claim 'B'. If you picked 'left', then E is still
claiming C, and F is still claiming 'B'. So you do *another* heads()
check, and then decide to pick 'left':
  left  C

So the big problem with 'left', is that this continues indefinitely.
Picking 'right', you get a bit of propagation, but it eventually settles
down. (criss-cross merges 'swap', but they are fairly rare on a per-file
level.) 'sorted' makes it settle the fastest.


Anyway, I'm fine breaking this out so that someone can do their own, but
I figured I'd write up the full discussion as to what is going on.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknQ0kwACgkQJdeBCYSNAAO23wCfZ7nAd09XkqZ1oeAEvaHnxsTD
4T4AmQHFP3slKv05iQ9+PVpZML+WPOX7
=MdGg
-----END PGP SIGNATURE-----



More information about the bazaar mailing list