On 1/14/2016 2:22 PM, Ross Berteig wrote:
On 1/14/2016 12:41 PM, Joe Mistachkin wrote:
Ross Berteig wrote:
It seems as if the --no-repository option had no effect at all.
Both fossils are built fresh from tip of trunk this morning.
Sorry, that was a minor typo when refactoring. Should work now.
Actually, I think the code was fine as it was. At least the new checkin
also fails the test, although when I run fossil sqlite3 --no-repository
by hand it clearly works. So I think I found the error. At line 53 of
merge5.test, it says:
exec fossil sqlite3 --no-repository ....
Which would be running whatever fossil is on the path, not the specific
version passed to tester.tcl as the version to be tested. Changing that to:
global fossilexe
exec $fossilexe sqlite3 --no-repository ....
allows it to run all tests in merge5.test without error. Alternatively,
just dropping the command "exec" might do the trick since the function
named "fossil" handles that call itself. Unless there is some quirk of
Tcl string quoting for the rest of the command line that causes trouble.
And with that edit (actually Joe's checkin [acbee54e8b]), the entire
test suite passes except for:
* merge_multi-4
* merge_renames-5
on Ubuntu and Windows.
Looking at the output for those two tests, it doesn't look like a false
positive, unless fossil's behavior under certain edge cases of merge has
changed. The merge_multi-4 case is expecting to see files f1, f2, f3,
and f4, but is missing f2. The merge_renames-5 case is expecting to have
files f1, f2, and f3, but is missing file f1.
Not having an expected file after merging seems like a bad result.
Mitigating that, these are edge cases surrounding interactions of DELETE
and RENAME with the merge, and I'm not claiming to know what should
really have happened here.
All I'm willing to claim is that if these test cases passed previously,
then fossil's behavior has changed. That could be intentional, in which
case the test cases should be updated to reflect the now expected behavior.
Or it could be a regression, in which case the test cases are doing
their job and found a bug that should be fixed.
And then there's the sort-of-related bug that vanished when its source
text test/utf.test was edited recently, where the 27th pass of pairs of
random edits to that file didn't 3-way-merge the same as those edits
applied separately. Every other 3-way-merge pass over that text and all
the other source texts, succeeds. That makes me nervous that there is a
subtle regression lurking.
The version that fails at pass 27 is:
http://www.fossil-scm.org/index.html/artifact/9b9447e346cbc663
A version that succeeds is:
http://www.fossil-scm.org/index.html/artifact/7fd75c8d3699ff96
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
