Bug : uncommit and deleted file
abentley at panoramicfeedback.com
Tue May 1 13:49:41 BST 2007
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
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
$ bzr commit -m "commit 1" sandbox
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
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.
More information about the bazaar