Comment 7 for bug 533152

Yes, it's a bit confusing, but:

> $ bzr st
> removed:
> dir/test.txt

This file doesn't exist anymore under this path.

> renamed:
> dir/ => dir2/
> unknown:
> dir2/test2.txt
This file is unknown under this path.

This is why --after was introduced: if you don't inform bzr about the renaming
(asking it to do it itself being of course the more robust), you can inform it
after the fact.

> If the status uses the old dir name

It reports about known (or previously known paths) and also about non-versioned but existing paths.

> but mv expects the new dir name

It requires an existing path for its first argument (the unknown one in that case)

> that feels a bit inconsistent to me.

The alternative will be to require the file_id and informs 'bzr mv' about the new path. As a policy we try to
never require internal identifiers at the UI level.

I realize that your script is a simplification of a real-life scenario where things were less obvious though...

Allowing several paths for the same file as you suggest seems... a bit brittle (resist the tentation to guess and all that :)
if several different files really exist.
There are ways to check for that, but I'm not sure it's worth the effort and will make the code more complex.

I'd prefer to give a better error message.

Also, better integrating with various GUIs is the way to go, but I'm not sure we can easily hook
into your file manager (which one by the way ?).

> so I would expect that I can tell bazaar any file that it thinks is removed is actually renamed instead.

May be you're searchiing for 'bzr mv --auto' ?

For the your script, replacing the final 'bzr mv dir/test.txt dir2/test2.txt' by 'bzr mv --auto' gives:
  bzr mv --auto
  dir2/test.txt => dir2/test2.txt