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.
That test is a loop over most files in the test folder, where each file
is used for 100 trials of a random edits test where two independent
edits are made and merged in both orders. The test case name means that
"utf.test" was the original file, and both edit orders failed to merge
on the 79th random seed.
The original file is t1.
Random edits of t1 with seed 79*2 make t2.
Random edits of t1 with seed 79*2+1 make t3.
Random edits of t2 with seed 79*2+1 make t23
Random edits of t3 with seed 79*2 make t32
At this point, t23 and t32 are likely to have the same content, I think,
unless the two changes overlapped in the right way.
The fossil 3-way-merge command is used to apply the edits in both
orders, giving files a23 and a32.
The test cases are the comparisons of a23 to t23 and a32 to t32.
For this seed of this source file, t23 and t32 happen to be identical,
but both a23 and a32 show a merge conflict (on the same span of lines,
at least). My guess is that what has happened is that the random edits
got too close together for comfort of the merge code. I don't like
having test cases fail in code that seems to sit at the heart of
fossil's features.
One "fix" would be to modify the merge2 fuzz testing so that if a
conflict appears, it skips that seed for that file. This seems like a
patch for a symptom however.
Since, of the 100 passes over each of the dozens of files in test/*,
this is the only case where a merge conflict happened, I suspect some
tuning of the parameters passed to random_changes() to further separate
the edits would also "fix" the failing test case. But that too seems
like patching the symptom and not solving the problem.
A better (but not necessarily practical) fix would be to understand why
those particular edits caused a merge conflict, and then to resolve that
to no conflict. As I understand the idea of a conflict, since t23 and
t32 are actually identical, there should not be any real conflict. That
is, the order of application of the edits did not matter.
I have zipped the files t1, t2, t3, t23, t32, a23, and a32 and put them
at [1] if anyone wants the raw data.
[1] https://www.cheshireeng.com/fossil/merge-utf-79.zip
Any thoughts?
--
Ross Berteig [email protected]
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-dev mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
