Re: [cdv-devel] more merging stuff (bit long...)

Bram Cohen wrote:

>   a
>  / \
> /   \
> b    b
> |\  /|
> a \/ a
> | /\ |
> |/  \|
> b    b
>
> On both sides we have one do and one implicit undo, so both sides merged
> clean to 'do', but when you put them together there are undos of both dos,
> so the result should clean merge to a, even though both ancestors are b.
> The best way to treat this case is that there's only a single value merged
> to, but a warning is escalated to the user that data may have become
> inconsistent, since this value may not have appeared alongside other
> values set to other things anywhere in the history.

This case warrants some further explanation. Let's say we label everything
as follows:

   a
  / \
 /   \
 Xb   Pb
 |\  /|
 Ya\/ Qa
 | /\ |
 |/  \|
 Mb   Nb

A reasonable criterion for a version control system should be that if
there are several values and they're clean merged together then what they
eventually merge to should be independent of the order of the merging. In
this case, clearly Y and Q should clean merge to a. Y and P (and X and Q)
should clean merge to b, by implicit undo. Therefore, M and N are both
clean merges. Since they represent the sum total of X, Y, P, and Q, they
should therefore merge to the same value as the merge of Y and Q (since
that also includes X and P), which, as previously mentioned, is a.

An example problem with this is if both M and N set another value which
has a dependence on the value a. Now you have two ancestors which are
completely consistent but a descendant which garbles them. Of course, it's
always possible for two interdependant variables to be set to inconsistent
values and then merged clean, so perhaps this case isn't all that
different and I'm being unnecessarily paranoid.

In any case, I'm going to make an updated version of new codeville merge
which gives much more verbose output - for each line, it gives whether
that line appeared on the left, right, common ancestor, mash-up (that's
merge without checking for conflicts) and whether it's part of a conflict.
Disturbingly, all 16 possible values for those first four variables can
actually happen, which creates a bit of a UI problem.

-Bram