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

[Martin Pool]

I would like this:

 * the standard command removes the working file
 * it refuses to remove it if that would lose data, unless --force is given
 * there can be a command to just unversion it

Basically this is the same as svn.  I'm sorry this wasn't clear in the bug.

I think this patch is too dangerous as-is.

When a change that removes a file is pulled into someone else's tree, it
will delete files that were removed unless there was a conflicting
change in the destination.  Currently you have the problem of

  bzr rm a/foo
  bzr commit -m 'remove foo' a
  bzr pull -d b a
  # foo is now deleted from b's working tree but still
  # present and unversioned in a

Therefore I think the standard "remove this file from the next commit"
should also delete it.  I don't think you should need a special option
as cvs does.

jamesh writes:

> A flag for rm/remove sounds good to me, but I'd suggest using "bzr rm
> -f" instead.  Both CVS and Subversion use -f or --force for "unversion
> + delete", so it seems silly to implement the same feature but pick a
> different name without a good reason. 

Actually it's quite different in cvs and svn: svn will delete unmodified
files whether you have -f or not.  This is safe, because you can restore
them by reverting to the previous version.  It cannot give irrevocable
data loss.  In fact it is possibly safer than the current recommendation
of just doing unix rm, because that has no such check.

If/when we delete directories, we should probably refuse (unless forced)
if they contain either modified or unknown files.

James Troup writes:

> Umm, for whatever it may be worth, I think this is a really bad idea.
> 
>  a) it's inconsistent with cvs
>  b) it's inconsistent with bzr << (0.15)[1]
> 
> In particular (b) is going to kill me.  I've very much got into the
> habit of doing 'bzr ignore foo; bzr rm foo' and I'm going to cry if
> that learned-meme leads to data loss when I one day run it on a host
> that's been upgraded to a newer version of bzr.

It's bad to change user interfaces but I think in this case it really
was a mistake.  It's inconsistent with cvs, but consistent with svn.
And if it is done as I propose it will not make you cry.

-- 
Martin