RFC: bzr rm is hard to use

Marius Kruger amanic at gmail.com
Fri Jul 17 05:39:09 BST 2009


2009/7/16 Martin Pool <mbp at canonical.com>

> Those rules sound ok to me. I prefer them to Ian's proposal because they're
> more similar to what merging the revision will produce.
>
> I think the only change is in how modified files are handled but it's
> clearer to describe the final state, as you did, not the delta.
>
> Deletion of unclean directories could be better to but that can be done
> separately and anyhow falls under "like revert".
>
> 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 assigned it to myself, since I implemented this in the first place and I
don't mind fixing it up (after I'm done with the log changes that is),
but if robert or anybody is more hasty, please feel free to coup it.


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ubuntu.com/archives/bazaar/attachments/20090717/9dc8a659/attachment-0001.htm 


More information about the bazaar mailing list