AW: RFC: bzr rm is hard to use
ian.clatworthy at canonical.com
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.
More information about the bazaar