Re: [cdv-devel] Re: precise codeville-merge reference now available

Here are some examples of weird merge cases, I'll skip ascii art in favor
of just giving the depedencies

Annotation is that X, Y -> Z('12') means 'revisions X and Y were merged to
form revision Z, which contains lines 1 and 2, in that order'. Asterisks
indicate clean merges.

A('')
A -> B('2')
B -> C('')
A -> D('2')
D -> E('')
B, E -> F('2') *
F -> G('12')
C, D -> H('2') *
H -> I('23')
G, I -> ?

In this case line 2 got deleted on both sides, so it should be deleted in
the descendant. The most broken behavior here is to clean merge to '123',
which is what sloppy codeville merge does. Somewhat less broken is to show
a conflict between '12' and '23', although that largely ensures that an
end user will put 2 in the cleanup, which shouldn't happen. About equally
broken to the last behavior is to show a conflict between '1' and '3',
which might look reasonable, but it's possible that both lines 1 and 3
have a strong dependency on line 2, so displaying them alone is garbled.

I think the best approach is to display more information than is
traditionally done in conflict cases.

Here's another wacky case:

A('')
A -> B('1')
B -> C('')
C -> D('1')
B -> E('')
E -> F('1')
C, F -> G('') *
D, E -> H('') *
A -> I('2')
I -> J('')
J -> K('2')
I -> L('')
L -> M('2')
J, M -> N('') *
K, L -> O('') *
G, N -> P('') *
H, O -> Q('') *
P, Q -> ?

This is a very strange case - both lines '1' and '2' should come back now,
but neither of them has ever appeared next to the other before, so their
order is ambiguous, and they may be completely garbled next to each other.

Again, I think the solution is to provide more information than is
traditionally done. '1' and '2' should both appear in the result, with an
arbitrary order and conflict annotation indicating what happened and that
the resulting code may be garbled.

-Bram