AW: RFC: bzr rm is hard to use

Ian Clatworthy ian.clatworthy at
Thu Jul 16 09:03:52 BST 2009

Voelker, Bernhard wrote:
> in advance: sorry for comparing with non-OS ClearCase.
> I still don't understand what exactly `bar rm` does or should do.
> Does it only remove a file entry from the directory "from now on"
> (so that it's possible to go back to an older version of that file),
> or does it entirely destroy the versioned file (forever)?
The former. We can't destroy history in a DVCS so the latter isn't
possible, short of regenerating a completely new history (using
fast-import-filter say) and getting everyone to abandon their existing
> In ClearCase, these are 2 different operations, and you can even
> merge back a file which has just been "taken out of service" a few
> revisions ago.
To get back a file that existed previously, I'd use something like 'bzr
revert -rxxx foo'.
> BTW: if you destroy a versioned file changed in the working tree
> in ClearCase, then it goes to a lost+found area. I like this.
> If it was not changed, I'd personally expect the file to be vanished
> from the file system after a `bzr rm`.
Compare your expected behaviour in those cases with 'bzr rm' on a file
yet to be committed. If I do:

  bzr add foo
  (damn, didn't mean that)
  bzr rm foo

then I certainly do *not* want Bazaar to remove the file from disk - I
just want it to forget about the 'bzr add'. Being both safe and
consistent here is the crux of the usability challenge IMO.

Ian C.

More information about the bazaar mailing list