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.
commands.revert calculates everything that has to be done and then
calls hg.revert to checkout and remove files. Unfortunately,
hg.revert has to recalculate everything and that can take a long
while, since it always operates on the whole working dir.
Changing commands.revert to manually checkout and remove files
makes things considerably faster, especially if we're reverting
a single file in a repo with a huge number of files.
This should be enough to close issue857.
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
(including small changes to revert and backout to not show these stats
with the exception of backout --merge)
Show update stats (unless -q), e.g.:
K files updated, L files merged, M files removed, N files unresolved
Inform the user what to do after a merge:
(branch merge, don't forget to commit)
Inform the user what to do if a branch merge failed:
There are unresolved merges, you can redo the full merge using:
hg update -C X
hg merge Y
Inform the user what to do if a working directory merge failed:
There are unresolved merges with locally modified files.
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)
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.