Bazaar

manual rename after bzr mv == incorrect status report

Bug #131792 reported by Alexander Belchenko on 2007-08-11

This bug report is a duplicate of: Bug #5158: rfc: don't treat missing files as deleted. Edit Remove

Affects		Status	Importance	Assigned to	Milestone
	Bazaar	Confirmed	Undecided	Unassigned

Bug Description

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.

Tags:

Revision history for this message

Aaron Bentley (abentley) wrote on 2007-08-11:

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

Revision history for this message

Alexander Belchenko (bialix) wrote on 2007-08-11: Re: [Bug 131792] Re: manual rename after bzr mv == incorrect status report

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.

Revision history for this message

Robert Collins (lifeless) wrote on 2007-08-12: Re: [Bug 131792] manual rename after bzr mv == incorrect status report

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>.