We now also test reverting file to another revision's content. However
this differs from previously introduced test by using the explicit path
of each "case file" when calling revert. This should result in the
same result regarding file content and backup creation, but the output
of the `hg revert` call should differ.
We now also test reverting file to the working directory parent
content. However this differs from the previously introduced test by using
the explicit path of each "case file" when calling revert. This should
result in the same result regarding file content and backup creation,
but the output of the `hg revert` call should differ.
Now that we can automatically generate states, we need to actually run
revert on them and check the result. While running such tests we are
checking multiple elements. The output of the `hg revert` command, the
resulting content of file, and the creation of backup file.
The first practical test is using the simple case `hg revert --all`, reverting
all files to working directory parent content.
The text version is just a list of existing files with their content. We use a
small custom script for that.
This is going to be very useful for comparing revert results with
revert target content.
There are multiple comments explaining the expected output of commands. This is
an old relic of the pre-unified test era. We remove them for uselessness.
We highlight the behavior tested by each sections. (This is a gratuitous
improvement before significant upgrade of the test and massive refactoring of
the revert code)
revert was always using p1 as parent. This created some minor misbehavior when
reverting against p2. See test change for an example of that.
This is also a useful cleanup for coming refactoring to revert.
This kind of revert is specifically trickier since the file is
reported as "modified" by status. This case was only tested by some
largefiles test. We introduce proper testing of all aspects of this
case in the revert tests themselves.
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.
