On 3/1/2016 3:04 PM, Joel Bruick wrote:
The following piece of boilerplate can be found in various Fossil test files:catch {exec $::fossilexe info} res if {![regexp {use --repository} $res]} { puts stderr "Cannot run this test within an open checkout" return }
A *very* similar fragment is also in repo_init, called from most of the test files.
I've come to realize that this code doesn't actually do anything useful, despite my best efforts to blindly copy and paste it into a couple of test files myself. In tester.tcl, the directory used as the working directory for the next test file is deleted and then recreated before the test file is evaluated, so the only thing it prevents you from doing is running the test if you somehow manage to open a checkout in that directory between the time it is created and the time that the above code is executed.
I think this is a remnant of history. Once upon a time, the tests were expected to be run with "make test" in the build directory. The block in src/main.mk that implements the test target has a very scary warning about running the tests tainting the repository so discard it when done. A number of the test cases really did require that the run from within not just some checkout, but a checkout of fossil's own repository. At some point, the test case implementation style began a slow shift towards independence of the main fossil repository, and that is likely when this fragment was introduced. When I began poking at the test framework recently, most cases were independent of the fossil checkout and tree. But there were a few lingering cases that needed the checkout. Those got fixed so that the entire test suite can (and really should) run from outside fossil checkout, and the remaining *very few* cases that need the checkout follow the path to tester.tcl to find it and are bound to make no changes to it. Personally, I think that "make test" should now print a brief message saying "Don't do that, please run tests in another directory" and fail. Alternatively, it could make a new folder in $TEMP, cd there, and run tester.tcl in there. Similarly, tester.tcl should probably check (right next to its verification that it has a temp folder would be good) and exit with an error if it can tell that it was started from anywhere in the fossil checkout. (Just looking up the project code should do the trick, it is stable across the entire lifetime of the fossil repository. If "fossil info" runs without error, you are in a checkout at all, if the project code is "CE59BB9F18..." that is is fossil's own repo.)
As someone who has accidentally called the test runner from an unintended directory once or twice (no damage done besides directory spam, thankfully), we should give testers some protection from having a directory unintentionally deleted because it shares the name of one of our test files.
I have a (growing) collection of folders each holding the result of ../fossil/configure --some-collection-of-options where I build and test various configurations. Anyone who names a test case bld.test (or after any of the other generated files written by "./configure; make") is in for at best a surprise and more likely some painful debugging. Don't do that.
My recommendation is simply to add a special suffix to each test directory name, so "merge_renames.test" is run inside the directory "merge_renames#fossil", for example.
That does seem sane. Assuming tester.tcl also guards against being run in the test folder (which it really should do) then just using the name of the test file would be a simple change. So it would run amend.test in a folder named amend.test. It would also be trivial to add a suffix. The '#' looks ugly, but is legal in file names on Unix, OSX, and Windows. There may be safer characters to pick as well. -- 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
