Comment 2 for bug 402196

Hi Martin

Thanks for the response.

quote: bzr --keep really means "keep in the working tree but delete from bzr"

-- yep, I understand that but --keep only seems to do that on the *current* working tree (the one I'm working on). The problem is that even when specifying --keep the file is removed from both disk and bzr in *other* working trees.

For instance, if I'm working with another developer and I remove a file from bzr using --keep, I'd expect the other developer's working tree to be updated when they pull from my working tree with the update being "remove this file from bzr but leave it on their disk".
If the file is removed from their disk then we have possible confusion, excess time spent etc etc.

Does that make more sense? basically I don't think bzr should be deleting files on disk when I've explicitly told it not to with --keep. Especially in the case that the file is an important part of the package. I'd rather that bzr in the --keep instance not make destructive changes to files.. I can always rm a file later if it is no longer needed on disk.

If I "bzr remove" a file without --keep then I expect it to be removed from bzr and disk -- no problems there.

In regards to "revert", I tried this using my example above in "remote":

$ pwd
/path to/remote
$ bzr revert unwanted.txt
bzr: ERROR: Path(s) are not versioned: unwanted.txt

Which is understandable because unwanted.txt is no longer in bzr and therefore cannot be reverted. My co-developer would therefore have to source another copy of the deleted file and ensure that it is up to date and valid, manually.

Thanks