RFC: bzr rm is hard to use

[Martin Pool]

2009/7/17 Marius Kruger <amanic at gmail.com>:
>> Maybe file a bug to record the apparent consensus?
>
> I filed a blueprint, I hope its the correct use of it since its my first
> dabble with blueprints:
> https://blueprints.launchpad.net/bzr/+spec/bzr-rm-behaviour
> I documented what looked to me like the 'apparent consensus', but feel free
> to comment or update it.

I don't think you're doing anything wrong with that blueprint as such,
except that normally the text of it is kept in the wiki or some other
source rather than in the whiteboard, which is not versioned.

The main feature of specs is that they can keep systematic track of
whether it's approved or not, and of different roles that people have.
 This issue of agreeing on approach as separate from implementation
does apply to this bug.  There's no rule that feature changes need to
be in specs and problems in bugs.

However, generally speaking we're not using specs very much and
they're not improving as fast as Launchpad Bugs are, so I really would
suggest a bug instead.  However, if you're going to work on this, you
can put it wherever you choose.

> We need to choose how would like it to work:
>
> Option1)
> * '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)
>
> * bzr rm - unversion the file
> * bzr rm --delete - unversion the file and delete it from disk
> who is going to make the call?

By consensus I meant option 1 but looking at later mail it may not be
consensus quite yet.

I wonder if these descriptions are glossing over some things?

If we agree on option 1, unifying the code with bzr revert would be nice.

-- 
Martin <http://launchpad.net/~mbp/>