bzr rm <file> loses data under some circumstances

[James Troup]

When 'bzr rm' was changed to start removing the copy on disk, I was
assured that it would never remove a file in such a way as to cause
data loss, i.e. it would only remove stuff that could safely be
recovered from version history. Except that I just ran into a case
where this isn't true:

 | $ touch precious
 | $ bzr init
 | $ bzr add precious
 | added precious
 | $ bzr ignore precious
 | Warning: the following files are version controlled and match your ignore pattern:
 | precious
 | $ bzr rm precious
 | deleted precious
 | $ ls precious
 | ls: precious: No such file or directory
 | $

(This, unfortunately, is not a hypothetical or contrived example, I
 just lost 70 or so files by doing something similar to the
 above. \o/)

--
James

[John A Meinel (jameinel)]

Just to comment, without the "bzr ignore precious" it gives:

$ bzr rm precious
bzr: ERROR: Can't safely remove modified or unknown files:
added:
  precious
Use --keep to not delete them, or --force to delete them regardless.

It is weird to me than "bzr ignore" is causing the files to not be kept.

I'm guessing the order:

bzr add precious
bzr rm precious # I didn't mean to add that
bzr ignore precious

Was sort of what you wanted, and in that order you would have been prompted for "--keep".

If you use "bzr rm --keep precious" in the above scenario, it does leave the file alone.

So we should figure out why a file matching an ignore pattern is causing us to auto remove it.

[Martin Pool (mbp)]

That is surprising, and quite a bug. It does seem to be the ignored match that makes the difference. It still happens with a non-empty file (not that we normally treat empty files differently, but I thought I'd check.)

[John A Meinel (jameinel)]

Patch available:
http://bundlebuggy.aaronbentley.com/request/%3C1196269723.5876.11.camel@laptop%3E

Seems to fix it for me.

As I called tweak and Robert approved it, I'll clean it up and submit it.

[John A Meinel (jameinel)]

merged into bzr.dev 3051

[Martin Pool (mbp)]

Yay, go Lukas!