Bug : uncommit and deleted file

[Aaron Bentley]

Erik de Castro Lopo wrote:

> I believe that since a.txt now exists, it should be a revisioned
> file with a history that goes back to when it was first added.

This is not a bug, because uncommit has never claimed to alter the tree
state.

As a feature request, I believe it is a bad idea, because we already
have "revert" to restore previous tree states, and it would interfere
with the common usage pattern:

  $ bzr commit -m bad-message
  $ bzr uncommit
  $ bzr commit -m good-message

This is because restoring file-ids can have side effects.  Two file-ids
must not refer to the same path, so restoring a file-id may require
moving an existing ID out of the way.  Consider

$ bzr init sandbox
$ touch sandbox/a
$ touch sandbox/b
$ bzr add sandbox
added a
added b
$ bzr commit -m "commit 1" sandbox
added a
added b
Committed revision 1.
$ rm sandbox/b
$ bzr rm sandbox/b
b does not exist.
$ bzr mv sandbox/a sandbox/b
a => b
$ bzr commit -m "Moved a onto b" sandbox
renamed a => b
deleted b
Committed revision 2.
$ bzr uncommit sandbox/

If, as you say, uncommit should restore the old "b", what do we do with
the new "b"?  It is in the way, because we can't have two entries for "b".

And if we do ANYTHING with the new b, then we have broken the "uncommit;
commit" behavior that people have come to rely on.

Finally, restoring old file ids requires changing file contents, because
the directory that the old file id was in may have changed from a
directory into a file.

I don't think people want that kind of unpredictability from uncommit.
We've got "revert" for doing what you want.  Use that.

Aaron