revert after pull of a revision that removes a file looses wt changes to that file

[Dato Simó]

It seems I managed to find a corner case in which revert seems to loose
information that is not recoverable.

Say revision X in some branch deletes file foo.txt. If you `bzr get -r X-1`,
edit foo.txt, then `bzr pull; bzr revert`, your changes to foo.txt will be
lost. Like this:

% bzr init foo; echo hi >foo/foo.txt; bzr add foo/*; bzr ci foo -m foo; bzr rm foo/foo.txt; bzr ci -m rm foo
added foo.txt
Committing to: /tmp/m/foo/
added foo.txt
Committed revision 1.
deleted foo.txt
Committing to: /tmp/m/foo/
deleted foo.txt
Committed revision 2.

% bzr get -r 1 foo bar; echo precious >>bar/foo.txt; cd bar && bzr pull && bzr revert && ls | wc -l
Branched 1 revision(s).
Using saved location: /tmp/m/foo/
RM foo.txt => foo.txt.THIS
Contents conflict in foo.txt
1 conflicts encountered.
Now on revision 2.
-D foo.txt.THIS
0 # <-- no backup of foo.txt done

 affects /products/bzr

[John A Meinel (jameinel)]

So... we conflict at the merge time, and put 'file.THIS' off to the side to indicate that you modified something which was deleted.

And then we want 'bzr revert' to notice that 'file.THIS' != 'file' @ when? I assume before the pull. Aaron, is there some way we can put that info into the 'merge-hashes' ?

My guess is it is partially failing because we blindly destroy the '.THIS' file, even though it is the current official location for that file-id.