Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments


Make bzr rm to Just Work, without always requiring --force or --keep when the file cant be removed safely.


"So, we've got a very complex 'bzr rm'. I don't know about you guys, but I'm starting to hate using it - I *always* end up having to type '--force' because we're hugely cautious." - lifeless

Further Details


Use Cases


UI Changes

Option 1) delete the files by default

  • 'bzr rm foo' - will make foo unversioned and delete foo, making backups when necessary with the same rules 'bzr revert' uses.
  • 'bzr rm foo --keep' - will only unversion (will not make backups).
  • 'bzr rm foo --force' or 'bzr rm foo --delete' - will delete the file regardless if it is safe and will not make backups.

Option 2) we keep the files by default

  • bzr rm - unversion the file
  • bzr rm --delete - unversion the file and delete it from disk

Code Changes

unifying the code with bzr revert would be nice.

We need to test the following scenarios:

  • 'bzr rm' of a missing file to Just Do It
  • 'bzr rm' of a file that has been modified by me to mv it to a backup using the same scheme 'bzr revert' does, and unversion it.
  • 'bzr rm' of an unmodified file to Just Do It
  • 'bzr rm --keep' on any of the cases above that remove the file to preserve the file on disk.
  • 'bzr rm foo --force' or 'bzr rm foo --delete' *IF* --force' is given then delete it.

Schema Changes

Data Migration


Unresolved Issues

Option 1) or 2) ?

It seems Option 1) is winning at the moment Current behaviour would already delete the files if it is safe. Now we would just backup your files if it is not safe in stead of annoying you.

'bzr rm foo --force' or 'bzr rm foo --delete' to delete the file

I think delete is better.

Questions and Answers

Should we tell the user when backing up files?

I assume we won't, but I'll look deeper into this and compare it to other commands when implementing it.

How are we to transition to this?

I think we need to deprecate --force and --safe for at least a release or two. i.e hide them, but don't throw errors when people use them from scripts etc, but rather print a deprecation warning.