RFC: bzr rm is hard to use

[Martin Pool]

2009/7/20 Robert Collins <robertc at robertcollins.net>:
> On Mon, 2009-07-20 at 11:04 +1000, Robert Collins wrote:
>> On Mon, 2009-07-20 at 10:28 +1000, Ian Clatworthy wrote:
>> >
>> > I think the command line UI ought to be equally simple. And it can be:
>> > 'rm foo' deletes the file so command line users can simply use that
>> > instead of 'bzr rm foo' if they want the file deleted. (Yes, there are
>> > edge cases but they shouldn't drive the core UI design IMO).
>>
>> I agree. I think 'bzr rm' should remove things - keeping backups is a
>> nice thing we can do without distorting the commands behaviour. We can
>> look at special casing some of the corner cases (like an
>> added-but-not-commited-file), but I don't think that that is needed.
>>
>> Having a seperate command to unversion things could be good too, though
>> I'm happy with 'bzr rm --keep' as a way to express that.
>
> Oh bah, I misread what you wrote :(.

I agreed with what Robert said, as opposed to Ian's idea.

To expand a bit on why I think it should remove them by default: bzr
cannot record the action of 'unversion this file but leave it in the
tree' - when you apply the delta elsewhere, the file will be removed.
So I think it's potentially going to confuse people if there's an rm
operation that when applied elsewhere causes the file to be deleted.
On the other hand, unversioning the file is a reasonable thing to want
and if we didn't support it, people would just need to work around it
by eg copying the file then restoring it.

I don't know if making it available but under an option is the best
resolution to this, but it does seem better than making it be under
bzr rm --keep.

Whenever this conversation wraps up or before there's a patch, I for
one would like to see the matrix of all the states and outcomes, to be
sure we didn't miss one.

If it's feasible it might be nice to make bzr rm use TreeTransform so
the backup etc code is done just there, rather than deleting things
itself.  That might require extending treetransform, perhaps it would
be too much.

> Uhm, I do agree that the command line should be very simple. I don't
> agree that 'bzr rm' should just-unversion. I think that 'bzr rm' should
> delete files on disk, and that we should make it safe by using our
> knowledge about whether the file can be recovered by the user + doing a
> backup when it can't.
>
> I think having 'bzr rm' *not* behave like 'rm' will confuse people - as
> in fact the very sentence you wrote about them managed to confuse me.

I think after 'bzr rm' in the normal case the file will be both
removed from disk and from the inventory.  Plain rm deletes only from
disk.  'bzr rm --keep' removes it only from the inventory.

I think the change Robert's wishing for here is to do with the
handling of cases where we might be losing user data: un-versioned or
newly-added or modified files.  At the moment, we refuse to do this
unless the user says --force and then we delete them entirely.  This
is fwiw consistent with GNU rm handling of readonly files.  In
practice I tend to run the command once, see it fail, then cursor up
and add --force.

There are other alternatives:

 * delete them but leave backups
 * just always delete them
 * add a 'yes/no/all/quit' prompt
 * move them to some trashcan-equivalent, from which they can be
automatically restored (like the first but with more metadata)

Adding backups means that for people who never make mistakes in
running the command there's no need to re-run the command.  It has the
drawbacks that it puts the work on the user to eventually delete the
backups and they may not be ignored by default, and they may clutter
the working tree.

Prompting may be a good chance to explain to the user why it's
happening but you still need an answer for noninteractive mode.  It
can in any case be added as -i.

You could, as a blue sky idea, put them in .bzr/checkout/trash or
.bzr/trash or have a configuration option to turn that on.  Of course
there was a comment early in the thread about the clearcase
requirement to poke through lost+found.

We might ask by what path does someone end up asking bzr to delete a
file that hits this case?

 1- I accidentally added a backup file; I don't particularly care
either way so it's ok to just delete it.

 2- I forgot I'd modified that file and on consideration I actually do
want to keep it.  (This does not seem likely but maybe it happens.)

 3- Yes, I did modify that file but then I decided to just delete it.
(To me, more common than 2.)

 4- I'm resolving a merge and though it has merge changes within it I
want to just kill it.  (Like 3.)

 5- I added my source file and I do want to keep it but not to add it
_yet_.  (I do this fairly often; in this case the right thing is 'rm
--keep' but people may accidentally rm it until they learn.)

 ... more?

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