People have complained that the current behavior of "revert" is dangerous:
- At least one new user has typed
monotone revertexpecting 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 revertaccidentally. 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.
- 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 revertby accident on the wrong thing, it only takes a second to get back to where you were. See .
- Add an option to say "yes, I mean everything". So, for instance,
monotone revert --alland
monotone revert foo/bar.txtwould be legal commands, but
monotone revertwould 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 srcwhen 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.
- 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!