manual rename after bzr mv == incorrect status report

[Alexander Belchenko]

E:\temp\444>bzr init
E:\temp\444>echo foo > bar
E:\temp\444>bzr add
added bar
E:\temp\444>bzr st
added:
  bar
E:\temp\444>bzr ci -m 1
added bar
Committed revision 1.
E:\temp\444>bzr mv bar foo
bar => foo
E:\temp\444>ren foo spam <<<<< manually rename file
E:\temp\444>bzr st
removed:
  bar <<<<<<<<< incorrect report, actually it should say `foo` removed
unknown:
  spam

E:\temp\444>bzr mv --after bar spam
bzr: ERROR: Could not rename bar => spam: bar is not versioned

Bang! And user has no idea what's correct name of file was.

Of course `bzr mv foo spam --after` works as expected.

[Aaron Bentley (abentley)]

This is intended behavior. Status compares the current tree to the last-committed tree, and the "bar" file is missing.

[Alexander Belchenko (bialix)]

Aaron Bentley пишет:
> This is intended behavior. Status compares the current tree to the
> last-committed tree, and the "bar" file is missing.

AFAIK, move operation is tracked in dirstate. So, dirstate is "know"
that file was moved/renamed.

If it's intended behavior then it's a bug in UI, IMO.

[Robert Collins (lifeless)]

On Sat, 2007-08-11 at 11:38 +0000, Alexander Belchenko wrote:
> E:\temp\444>bzr mv bar foo
> bar => foo
> E:\temp\444>ren foo spam <<<<< manually rename file
> E:\temp\444>bzr st
> removed:
> bar <<<<<<<<< incorrect report, actually it
> should say `foo` removed

There are two paths related to the missing file:
bar in the basis
foo in the current tree

I think the crux of the UI issue here is the implicit deletion - if we
reported the file as missing we could say
missing:
  bar => foo

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.