[MERGE] bzr rm should delete the working file (Bug #82602)

[Martin Pool]

On 4/13/07, John Arbash Meinel <john at arbash-meinel.com> wrote:
> Thomas Ackermann wrote:
> > John Arbash Meinel schrieb:

> > Just jumped in and felt the need to comment:
> >
> > "bzr rm" should never actually remove a file!
> >
> > It is a command to "bzr", not to the filesystem!

Being very careful about deleting data is the reason why it has the
behavior it currently does.  But consider what happens when another
working tree merges or updates to the revision in which the file was
removed: it will delete the file, unless it was locally modified.
This is inconsistent with what happened in the original working tree.

(And the inconsistency can cause trouble if I unversion a file, test
and commit, but the tests only pass because the unversioned file is
still hanging around.)

> There are a couple different ways of using 'bzr rm'. For *me* if I'm
> 'rm' ing a file, I'm done with it. The chance that I want to unversion a
> file but not actually delete it is in the low fractions of a percent
> case.

Me too.

> So having to do "bzr rm foo; rm foo" is a pain. Especially
> considering "bzr mv foo bar" moves it for me, and "bzr mkdir dir" will
> create the directory, etc.

As aaron says you can just rm it, but I think we should still fix it
because of the inconsistency with commit, and because as you say it's
safer.

> Having "bzr rm foo" delete the file if it is unmodified and fail
> otherwise is actually safer than expecting users to use "bzr rm foo; rm
> foo". Because 'rm' doesn't check that there are no changes to the file.
>
> And I agree with Aaron about using a RegistryOption, since --force,
> --keep, and --auto are modifying the same behavior, rather than separate
> flags. (You can't --force and --keep at the same time)

Agree.

-- 
Martin