remove --keep deletes files from disk in remote branches

[James]

Hi

I've noticed that if a file gets added to version control and is then removed but kept on disk using --keep then the same file is removed from disk on remote branches.

A use case is where, say, a config file is added to a local branch and merged into a remote branch. If that config file is removed from bzr using "bzr remove --keep file.ext" because it's decided that it should not be stored in version control, then that same file is deleted from disk on the remote branch.

The file should actually be kept on disk as the --keep flag is used, I understand that the file probably shouldn't be in bzr in the first place but in some cases this happens. The file being removed from disk can cause flow-on problems (e.g maybe it's an application config file for a website) -- the file then needs to be recreated manually which can be an annoyance.
A workaround is to dive in to the remote branch and make a copy of the file before the branch is updated then move the file back into place after the update. This is also an annoyance.

from the help docs:
bzr help remove:
"--keep Don't delete any files."

Simple command flow:

$ mkdir source
$ cd source
$ touch foo.txt
$ touch bar.txt
$ touch unwanted.txt
$ bzr init .
Created a standalone tree (format: pack-0.92)

$ bzr add
adding bar.txt
adding foo.txt
adding unwanted.txt

$ bzr commit -m "initial commit"
Committing to: /path/to/source/
added bar.txt
added foo.txt
added unwanted.txt
Committed revision 1.

$ cd ../

$ bzr branch ./source remote
Branched 1 revision(s).

$ cd remote

$ ls -la
total 12
drwxr-xr-x 3 james james 4096 2009-07-21 22:12 .
drwxr-xr-x 4 james james 4096 2009-07-21 22:12 ..
-rw-r--r-- 1 james james 0 2009-07-21 22:12 bar.txt
drwxr-xr-x 6 james james 4096 2009-07-21 22:12 .bzr
-rw-r--r-- 1 james james 0 2009-07-21 22:12 foo.txt
-rw-r--r-- 1 james james 0 2009-07-21 22:12 unwanted.txt

$ cd ../source/

$ bzr remove --keep unwanted.txt
removed unwanted.txt

$ bzr commit -m "remove unwanted file that should not be version controlled"
Committing to: /path/to/source/
deleted unwanted.txt
Committed revision 2.

$ ls -la
total 12
drwxr-xr-x 3 james james 4096 2009-07-21 22:12 .
drwxr-xr-x 4 james james 4096 2009-07-21 22:13 ..
-rw-r--r-- 1 james james 0 2009-07-21 22:12 bar.txt
drwxr-xr-x 6 james james 4096 2009-07-21 22:12 .bzr
-rw-r--r-- 1 james james 0 2009-07-21 22:11 foo.txt
-rw-r--r-- 1 james james 0 2009-07-21 22:12 unwanted.txt

$ cd ../remote
$ bzr pull
Using saved parent location: /path/to/source/
-D unwanted.txt
All changes applied successfully.
Now on revision 2.
$ ls -la
total 12
drwxr-xr-x 3 james james 4096 2009-07-21 22:13 .
drwxr-xr-x 4 james james 4096 2009-07-21 22:13 ..
-rw-r--r-- 1 james james 0 2009-07-21 22:12 bar.txt
drwxr-xr-x 6 james james 4096 2009-07-21 22:12 .bzr
-rw-r--r-- 1 james james 0 2009-07-21 22:12 foo.txt

After the bzr pull in "remote" I'd expect unwanted.txt to be kept on disk but removed from bzr -- is that a correct assumption or is this behaviour by design in remove --keep ?
If I had just used "bzr remove" then I'd expect unwanted.txt to be removed from bzr and disk as has happened above.

This also happens whether the "remote" branch is on the same disk or on a remote server over sftp.

Thanks
James

$ bzr version
Bazaar (bzr) 1.16.1
  Python interpreter: /usr/bin/python 2.6.2
  Python standard library: /usr/lib/python2.6
  bzrlib: /usr/lib/python2.6/dist-packages/bzrlib

installed from ubuntu packages

[Martin Pool (mbp)]

I can see why you'd want this in this case, and it's a reasonable case, but it's not a bug so much as a misunderstanding of bzr.

bzr --keep really means "keep in the working tree but delete from bzr". The results in terms of what's committed are the same whether you use --keep or not. Possibly this should be made more clear in the documentation or help, with eg

            keep='Delete from bzr but leave the working copy.',

Would that have made it more clear?

It would be a separate feature request to have a way to update a tree without deleting files.

For now I suggest you in the updated tree use 'bzr revert' to extract the wanted revision of the configuration file...

[James (james-ellis-gmail)]

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

[James (james-ellis-gmail)]

I was just chatting with a co-developer who agrees that files in working trees should be deleted from disk when --keep is specified but that --keep should only apply to the current working tree where the command is entered.

We suggest another flag "--keep-all" or "--keep-everywhere" to tell bzr not to destroy files in remote working trees (and the current working tree)

Cheers
James

[James (james-ellis-gmail)]

Damn, cold fingers and I don't see an edit button. Try again

"I was just chatting with a co-developer who agrees that files in working trees should *not* be deleted from disk when --keep is specified .......... "

[Robert Collins (lifeless)]

On Fri, 2009-07-24 at 00:41 +0000, James wrote:
> 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.

This seems to be an expectation setup by having the option --keep to
remove. bzr's data structure is snapshot based - as such we record state
('foo' is versioned) rather than actions ('foo' should be unversioned).
If we recorded actions, we could add an action ('foo' should be
unversioned-and-kept).

But we don't, and this makes doing the sort of change you are proposing
significantly complicated. I can see the use case, but I don't think
we'll do this ourselves.

When bzr removes a file in the other developers tree, they can restore
the file by doing 'bzr revert FILENAME; bzr rm --keep FILENAME'. If they
had local edits to the file, then bzr will conflict on it rather than
just deleting it.

 importance wishlist
 status triaged
 done

-Rob

[Martin Pool (mbp)]

2009/7/24 James <email address hidden>:
> I was just chatting with a co-developer who agrees that files in working
> trees should be deleted from disk when --keep is specified but that
> --keep should only apply to the current working tree where the command
> is entered.
>
> We suggest another flag "--keep-all" or "--keep-everywhere" to tell bzr
> not to destroy files in remote working trees (and the current working
> tree)

You can file a feature request for that if you like.

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

[Martin Pool (mbp)]

2009/7/24 Martin Pool <email address hidden>:

> You can file a feature request for that if you like.

... ie as a bug.

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

[Martin Pool (mbp)]

2009/7/24 Robert Collins <email address hidden>:
> But we don't, and this makes doing the sort of change you are proposing
> significantly complicated. I can see the use case, but I don't think
> we'll do this ourselves.

You could have 'bzr update --no-deletions', and know to run that on
the remote machine. I don't know if that's very useful, and it's such
an edge case I'd question whether it's worthwhile.

Alternatively we could introduce a category of precious (as distinct
from ignored) files, and not delete them when a file changes from
being versioned to precious/unversioned. Again I question the
importance.

>
> When bzr removes a file in the other developers tree, they can restore
> the file by doing 'bzr revert FILENAME; bzr rm --keep FILENAME'. If they
> had local edits to the file, then bzr will conflict on it rather than
> just deleting it.

You apparently need to specify the right version to revert to if
you've pulled, rather than merged.

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

[Martin Pool (mbp)]

James,

What I was thinking of when I mentioned bzr revert was actually bzr
undelete: https://launchpad.net/bzr-undelete

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