bzr losing track of file in aborted commit of rename

[Arjen Lentz]

# in bzr 1.7 reproduce as follows:
mkdir test
cd test
bzr init
touch foo
bzr add foo
bzr commit

mv foo bar
# abort the following commit, because we realise we should've done the rename through bzr
bzr commit
mv bar foo
# the following will now come up with "bzr: ERROR: Could not rename foo => bar: foo is not versioned."
bzr mv foo bar

[Martin Pool (mbp)]

What's happened here is that the original commit, after the file was moved away with plain 'mv', is that bzr implicity unversioned the file. So when you later move it back, as bzr says it's unversioned. If you realize the original commit is wrong, it's better to uncommit it and fix it up.

[Martin Pool (mbp)]

This probably counts as evidence for the design that commit should not automatically remove missing files.

[Arjen Lentz (arjen-lentz)]

Ah. Ye let's not automatically remove missing files, just like new files are not automatically added.
If you want such behaviour, they should possibly be controlled through ONE switch (for both) that is OFF by default.

I understand I can restore the dirstate by doing "bzr revert foo" but that's a workaround. It'd be great to just see this fixed up so I (and probably others who do this) don't get tripped up. I do this all the time now ;-)
The rename support is so important...

[Robert Collins (lifeless)]

 status triaged
 importance high

The cause of this bug is actually a probable cause for many of the
niggling 'commit died and left me in a bad way' issues - the MutableTree
method 'commit' is not rollingback the dirstate to unmodified on
failure.

We don't have a supported 'rollback' method on MutableTree that I could
find, the closest is _reset_data - perhaps this is a good time to create
one.

-Rob