revert/shelf/undo/redo

Martin Pool martinpool at gmail.com
Wed Oct 19 04:12:17 BST 2005


mpe's shelf plugin (also in bzrtools) is very cool, and i encourage
people who have not yet used it to try it out.  It shows all the
changed diff hunks in the working tree and lets you choose which ones
you would like to keep, and the others are set aside into .bzr-shelf.

We also have 'bzr revert' which undoes all changes to reset the
directory back to the previous revision.  As has been recently
discussed, this has some risk of destroying user data.  To fix the
most immediate problem we should probably give revert an option that
says whether newly-added files should be deleted or just unversioned.

The Arch solution to this is more or less, that the "undo" command
saves a changeset representing the uncommitted changes are stored to a
file called (approximately) ,,undo-1, and then removes them.  They can
be restored by just applying the changeset, which is what the redo
command does.  You can have several of these files.  This is a rather
elegant way to allow stacked undo operations on the working directory.
 There should be less worry about deleting files or making backups
from the revert command because any deleted content can be easily
removed.

So we could perhaps adopt this approach.

I'd like to at least keep 'revert' as an alias.

In practice 'tla undo' would sometimes fail because of trouble
generating or applying the changeset, which is annoying because
'revert' should be a way to get back to a known state.  I don't see
any in-principle problem in making it reliable; it's just a matter of
testing.

The changeset needs to keep track of any pending-merges (which I think
can be done by the current code.)

The 'redo' command to reverse an undo can potentially generate
conflicts if the files have changed in the meantime.

It would be nice to factor out the hunk-picking parts of shelve and
make them reusable by this and perhaps by 'commit --interactive'.

It would be nice if both undo and redo could take a list of selected files.

In the first cut it would be OK if there was not a stack but just a
single undo slot.  If we do have a stack, eventually it might be nice
to be able to redo them out of order.  (Or perhaps this gets too
complex.)  I suppose people can always apply them by hand.

So to sum up:

  bzr undo [FILE]
     revert and save changes to given files or directories, or to the
whole tree.
     if the whole tree is reverted, also clears the list of pending merges.

  bzr redo [FILE]
     restore undone changes to selected files, or the whole tree.

Any comments (particularly from people who might have used arch?)

--
Martin




More information about the bazaar mailing list