Many tests didn't change back from subdirectories at the end of the tests ...
and they don't have to. The missing 'cd ..' could always be added when another
test case is added to the test file.
This change do that tests (99.5%) consistently end up in $TESTDIR where they
started, thus making it simpler to extend them or move them around.
Globbing is usually used for filenames, so on windows it is reasonable and very
convenient that glob patterns accepts '\' or '/' when the pattern specifies
'/'.
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
Uncommitted changes (using --all *will* nuke edits):
$ hg revert
abort: no files or directories specified
(uncommitted changes, use --all to discard all changes)
Clean working directory (using --all won't discard anything):
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
and explicitly warn about uncommitted changes
Examples:
BEFORE:
$ hg par -q
7:e81a2efd53d4
$ hg revert -r 2
abort: no files or directories specified
(use --all to discard all changes)
AFTER:
Clean working directory (revert can be easily undone, no edits to be lost):
$ hg revert -r 2
abort: no files or directories specified
(use --all to revert all files, or 'hg update 2' to update)
Uncommitted changes (revert --all *does* discard edits and is pretty hard to
undo or even impossible if --no-backup is specified):
$ hg revert -r 2
abort: no files or directories specified
(uncommitted changes, use --all to discard all changes, or 'hg update 2' to update)
BEFORE:
$ hg revert
abort: no files or directories specified
(use --all to revert all files)
AFTER:
$ hg revert
abort: no files or directories specified
(use --all to discard all changes)
This reduces documentation confusion between the need to:
a) hg revert -a -r . (drop all changes from a merge)
b) hg up -C . (drop the second parent entirely)
Currently revert is one of two commands (the other being tag) that
still complains about uncommitted merges, dating from its former use
of a generic defaultrev function that aborted.
Many tests fixed the commit date of their changesets at '1000000 0' or
similar. However testing with "Mon Jan 12 13:46:40 1970 +0000" is not
better than testing with "Thu Jan 01 00:00:00 1970 +0000", which is
the default run-tests.py installs.
Removing the unnecessary flag removes some clutter and will hopefully
make it clearer what the tests are really trying to test. Some tests
did not even change their output when the dates were changed, in which
case the -d flag was truly irrelevant.
Dates used in sequence (such as '0 0', '1 0', etc...) were left alone
since they may make the test easier to understand.