People have complained that the current behavior of "revert" is dangerous:

> Problems

• At least one new user has typed monotone revert expecting to get a helpful usage message. Apparently with svn, this would have worked.
• Even for old users, it may be too easy to type monotone revert accidentally. Example: trying to type monotone revert 'read me.txt' and hitting enter instead of the quote mark.
• revert does not tell you what it has done, so you can't even see that you have made a mistake.

Ideas

• List what we are doing, similar to update. This seems like a no-brainer.
• Add undo support. This is complex, but a seriously good idea in any case -- revert and update are both dangerous commands, and dangerous is bad. This would seem to totally fix the first 2 issues above; even if you occasionally run monotone revert by accident on the wrong thing, it only takes a second to get back to where you were. See ?WorkingCopyUndo.
• Add an option to say "yes, I mean everything". So, for instance, monotone revert --all and monotone revert foo/bar.txt would be legal commands, but monotone revert would not be. The idea isn't so much to make the user think ahead, because users just get muscle memory for the special option and you end up accomplishing nothing (cf. rm -f). But, there is still an argument for this because it
  • prevents new users from making mistakes
  • stops accidental runs in experienced users, by increasing the distance between what they wanted and what would delete all their work. (Of course, one could still type monotone revert src when one wanted monotone revert src/Makefile.) The downside to this command is that it breaks symmetry between "revert" and the other restriction using commands ("status", "commit", "diff", "ls ignored/missing/unknown"). If it makes use more comfortable, though, the tradeoff may well be worth it.

The idea of adding "monotone ls changed" to show what revert will hit also came up. It's not too different from "monotone status", but perhaps would be useful.

Any others?

Possible conclusion

• definitely list what we are reverting
• definitely add undo support, but not necessarily right now
• ask the list what they think of revert --all, there may or may not be consensus.

Current Status (Feb 7, 2007)

• revert now requires a path so you must type 'revert .' to revert everything
• revert now lists things as it reverts them

Still To Do

• revert should probably be non-recursive and require -R or --recursive as add and drop now do
• revert (restrictions in general) should understand a peg revision syntax to disambiguate names from the old/new workspace rosters
• revert should perhaps have an option to revert only file content etc. rather than content, renames, attrs, etc.

Objections to this conclusion

• symmetry between status/diff/revert/commit seems good because it allows revert/commit commands to be "tested" with corresponding status/diff commands

your words here!