This doesn't make a difference right now, but after the next revision
some files in state 'a' may end up in the deleted list, and revert
won't be able to just remove all files in that list.
That's just an artifact of the current implementation, and I'll change
that soon.
Bonus points:
- we don't care about the unknown list at all
- we don't print an extra message if we try to revert a removed file
that is not present in the target revision
when a directory was given instead of a file it reported
incorrectly 'No such file or directory in rev <rev>'
we test if the file is a prefix directory
Rationale:
- When the user wants to revert, he shouldn't be stopped from doing
this just because some old backups will be overwritten.
- To not clobber important files by accident, alternative names for backup
files were disabled. As the backup target now has a fixed name, the user
doesn't have to be informed about the backup copy (unless --verbose)
new version does these things:
- saves backup copies of modified files (issue 147)
- prints output like other commands, and errors when files not found
(issue 123)
- marks files added/removed (issue 93)
Some systems show "Thu Jan 01" instead of "Thu Jan 1", which breaks tests.
Using "1000000" yields "Mon Jan 12 13:46:40 1970", which looks the same on
all systems.
if a file was of unsupported type, it was considered as 'seen' while
walking. this way it was possible to have file in the dirstate not
yielded by the walk function.
