On 9/28/2016 3:55 PM, Ross Berteig wrote:
For some time now, the test suite has been noting two errors from
merge2.test: merge-utf-79-23 and merge-utf-79-32. As of[0661d65c]these
are the only failing tests on trunk.
And apparently while I was researching this, drh was busily anticipating
my next move and made three check-in on trunk related to diffs. One or
more of those changed the diffs used by the three way merge just enough
that the specific cases merge-utf-79-* now pass.
I updated trunk to [233e9328ee], built and re-ran the merge2 test as
usual (100 passes over all files). Since fuzz testing is ever fickle,
merge-utf-48-* now fails, and rather more spectacularly than the earlier
simple conflict.
Now, a32 shows a merge conflict. But a23 does not. The files t23 and t32
are still identical. The files a23 and a32 are rather different.
Again, I've put a ZIP of the raw data up at [1].
[1]: https://www.cheshireeng.com/fossil/merge-utf-48.zip
So now I'm concerned that tweaks to the diff algorithm have caused a
dramatic but rare change to the three way merge.
Going out on a limb, I suspect the highly self-similar content of
utf.test is partly at fault here. The bulk of the file consists of minor
variations of the same block of lines, which is likely confusing something.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
