Re: [cdv-devel] tree merging

Nathaniel Smith wrote:

> I'm trying to understand how cdv-merge applies to tree rearrangement
> merging.
>
> Say we have a standard criss-cross merge case, where some file's name
> is the conflict:
>     A
>    / \
>   P   Y
>   |\ /|
>   | X |
>   |/ \|
>   Q   Z
> The file is named "foo" in A, "bar" in P and Q, and "baz" in Y and Z.
> We, of course, want to merge Q and Z.
>
> Q and Z have different values, so we get a first-order conflict, and
> look to see if we can resolve it.  Q's last-changed rev is P, and P is
> an ancestor of Z, so Q wants to lose; likewise, Z's last-changed rev
> is Y, and Y is an ancestor of Q, so Z wants to lose -- basically, this
> is a classic ambiguous clean merge.  Unlike ambig cleans found in text
> merging, though, it doesn't seem like we've been sloppy about identity
> -- there's a single atomic-valued cell being merged here, no questions
> of identity at all...
>
> What does codeville do in this case?  Or perhaps I should ask what
> codeville _should_ do in this case? :-)

I'm not sure off the top of my head. I *think* that one comes up as an
ambiguous clean merge, which is presented to the user the same as any
other conflict. We've waffled a bit on this one, and the way it currently
works is more based on a desire to not add new bugs than ideal behavior.
The really interesting case is the following one:

      A
     / \
    /   \
   /     \
  P       W
  |\     /|
  | \   / |
  |  \ /  |
  Q   X   Y
  |  / \  |
  | /   \ |
  |/     \|
  R       Z
   \     /
    \   /
     \ /
      ?

A is foo, P and W are bar, and Q and Y are foo. R and Z should both clean
merge to bar, because there's a do/undo on one side and a do on the other,
but currently they don't. Further, if R and Z are both bar then merging
them together should result in foo but with an ancestor conflict, which is
basically a 'this might be garbled' warning with no alternate version.

-Bram