uncommit after commit that removed a file leaves it unversioned

[Martin Pool]

erikd writes:

I think I've found a little corner case bug with bzr uncomit.
Here are the set of comamnds I run:

   cd /tmp/
   mkdir test
   cd test/
   bzr init
   echo "Just a test" > a.txt
   bzr add a.txt
   bzr commit -m "Add file a.txt."
   mv a.txt b.txt # Oops should have been "bzr mv"
   bzr commit -m "Rename a.txt to b.txt."
   bzr uncommit
   mv b.txt a.txt

Now, "bzr status" gives:

   removed:
     a.txt

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.

[Martin Pool (mbp)]

This is indeed a bug.

The first mv means that a.txt is missing (added but not present) and b.txt is unknown. As of bzr 0.16cr2, missing files are assumed by commit to be intentionally removed, so they are both omitted from the inventory stored by commit and also removed from the working inventory, which is rewritten by commit. This means that after a commit, we can't distinguish files which were versioned but missing from files that were not versioned at all - the information is lost and uncommit can't get it back.

As a workaround, 'bzr add a.txt' should re-add it with the same id, connecting it to its history - not great I know. Or save any modified files and revert.

I would say the fix for this is probably to treat missing files more like in svn: complain about them in commit, but don't remove them from the working inventory.

[Martin Pool (mbp)]

Changing the behaviour of missing files is bug 5158.

[Robert Collins (lifeless)]

So strictly, uncommit is doing the right thing - we define it as not reversing commit changes, just popping the pointer in the branch. If uncommit did reverse deltas there would be an easy way of just redoing a commit.