I seem to have the test suite bee in my bonnet this week. I'd like the
suite to execute cleanly for fossil 2.1, which it no longer doesfor
reasons related to SHA3.
The most obvious case is that there are numerous spots in the test suite
where command output is parsed to recover some hash value for use
inbalance of a test case. A typical example is used in amend.test,where
we find the functions uuid_from_*that all act like this:
proc uuid_from_commit {res var} {
upvar $var UUID
regexp {^New_Version: ([0-9a-f]{40})$} $res m UUID
}
That regexp is clearly seeking a UUID exactly 40 characters long. This
worked fine in fossil 2.0, which never created an SHA3 hash, and of
course in earlier versions where SHA1 was the only possibility.
One answer is to match the expectation of version 2.1 and later: a new
repository uses SHA3, so UUIDs are exactly 64 characters long. Another
is to allow either length.
Another answer would be to tweak the test_setup function to use fossil
init --sha1, but that seems like cheating. For the recordmaking that
change to test_setup does allow amend.test to once again pass all tests.
The regexp clause [0-9a-f]{40} appears in 10 placestotal in amend.test,
set-manifest.test, th1-docs.test, th1.test, and unversioned.test. I'm
not sure yet if any other tests somehow depend on the 40 character
assumption in another way.
Several tests build repositories with specific artifacts directly from
SQL dumps. At the moment, those all build repositories that have SHA1
hashes, and have matching schema. Tests in merg5.test failed because the
saved schema for the config table did not include an mtime column or
values stored in it. The fossil sqlite3 command used to reconstitute the
test repository from that SQL tried to execute the SQL
REPLACE INTO config(name,value,mtime) VALUES('hash-policy',1,now())
which failed, and left the test environment broken.
It would seem likely that the fossil sqlite3 --no-repository command
should not be injecting any SQL of its own, or more to the point,
changing the repo it opened in any way other than what was specifically
requested through the SQLite shell. If that were fixed, then a test case
like merg5.test would likely run just fine, although it would be using
SHA1 for its tests.
Note that fixing merge5.test to use SHA3 instead is a bigger task since
it compares the full hashes of every artifact it creates through its tests.
--
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
