Re: precise codeville-merge reference now available

Some issues turned up after the reference code release last night. Nothing
major, thankfully. They all center around the cases where a line either
appears in both of the ancestors but not in the clean merge, or doesn't
appear in either ancestor but does appear in the clean merge.

First of all, I had some broken code trying to hack around the problem I'm
about to explain. It proved to be broken (sort of, bear with me). I fixed
that and silently updated the code at the url I pointed to. That was an
easy fix.

Second, there's some broken behavior with conflict cases. Actually,
scratch that, conflict UI is broken in *all* systems out there, and I'm
just grumbling about it because the problem is made quite glaring by
running through some examples using precise merge. Basically you can have
a case where a line is not present in both ancestors but should be present
in the descendant, or isn't present in both ancestors and should be
present in the descendant, and in those cases *both* sides of a conflict
will have it wrong.

The simplest example of this is where version A adds a line, then version
B deletes it, concurrently version X adds the same line, and version Y
deletes it. Merging A and X will result in the line being added, likewise
with B and Y, but merging the result of those two merges will result in
the line being deleted.

Since this is a problem which has been present in all version control
systems to date, and nobody's really complained about it, I don't think
it's urgent to fix it. Probably the best approach is to make a more
verbose UI which actually explains these cases.

A related problem to the above one is that those weird agreeing with
neither parent cases can cause a two lines to border each other in a
descendant which have never bordered each other in any ancestor. In fact
it's possible to construct a case of two lines both of which must appear
in the descendant but not in either ancestor where their ordering must be
determined based on the arbitrarily chosen weave ordering.

The fix for this is to treat a descendant which differs from both
ancestors as a unitary conflict case, and mark it as such in the UI. I
haven't written the code for this yet, but it won't be very difficult.

Other than those cases it seems good so far. I've even got a good idea
about how to do dynamic line ordering, so the pie in the sky feature list
may get done far sooner than expected.

-Bram