RFC: bzr rm rethink

[Martin Pool]

On Sat, Aug 9, 2008 at 1:48 AM, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> John Arbash Meinel writes:
>  > 1) It is *safe* to do "bzr rm foo", because it will only remove the
>  > files if they are unmodified (aka, you can get back the contents with
>  > bzr revert.) Which is actually safer than "rm foo; bzr rm".
>
> How about an option --autocommit-changes, which automatically commits
> (and warns!) the modifications to the files slated for removal from
> the workspace?  This would also be *safe* in the same sense (by
> definition there will never be any uncommitted changes!)

That would be interesting (also for revert, merge into a modified tree
and other things that could lose file copies), but it would need to
have some reference to it, not on the main branch, that was reasonably
understandable.  This may not be so hard, another revision spec would
do.  Ideally it would go somewhere that could be gc'd after an
appropriate amount of time, and perhaps not into the main repository.

But I think this is mostly orthogonal.  Even if it was possible to
recover the file text I think users (especially less advanced) would
be happier not having it removed from the working tree without
checking.

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