"File id already exists in inventory" during bzr mv

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicholas Allen wrote:
> Public bug reported:
>
> I moved a file in my file manager and then went to the terminal to tell
> Bazaar that the file had been moved. When I did this I got an error:
>
> bzr: ERROR: File id {test.txt-20100306081700-27rpkfg2xoqgtgku-1} already
> exists in inventory as
> InventoryFile('test.txt-20100306081700-27rpkfg2xoqgtgku-1', u'test.txt',
> parent_id='dir-20100306081647-mc3jstj6biyq8tka-1', sha1=None, len=None,
> revision=None)
>
> This bug can be reproduced in 2.1 using the following commands:
>
> $ bzr init bzr-bug
> # cd bzr-bug
> $ mkdir dir
> $ bzr add
> adding dir
> $ echo text >> dir/test.txt
> $ bzr add
> adding dir/test.txt
> $ bzr ci -m "Add files"
> Committing to: /home/nick/tmp/bzr-bug/
> added dir
> added dir/test.txt
> Committed revision 1.
> $ mv dir dir2
> $ mv dir2/test.txt dir2/test2.txt
> $ bzr st
> removed:
> dir/
> dir/test.txt
> unknown:
> dir2/
> $ bzr mv dir dir2
> dir => dir2
> $ bzr st
> removed:
> dir/test.txt
> renamed:
> dir/ => dir2/
> unknown:
> dir2/test2.txt
> $ bzr mv dir/test.txt dir2/test2.txt
> bzr: ERROR: File id {test.txt-20100306081700-27rpkfg2xoqgtgku-1} already exists in inventory as InventoryFile('test.txt-20100306081700-27rpkfg2xoqgtgku-1', u'test.txt', parent_id='dir-20100306081647-mc3jstj6biyq8tka-1', sha1=None, len=None, revision=None)
>
> Here is the output of bzr version:
>
> Bazaar (bzr) 2.1.0
> Python interpreter: /usr/bin/python 2.6.4
> Python standard library: /usr/lib/python2.6
> Platform: Linux-2.6.31-19-generic-x86_64-with-Ubuntu-9.10-karmic
> bzrlib: /usr/lib/python2.6/dist-packages/bzrlib
> Bazaar configuration: /home/nick/.bazaar
> Bazaar log file: /home/nick/.bzr.log
>
> ** Affects: bzr
> Importance: Undecided
> Status: New

 status: confirmed
 importance: medium

I think there is something wrong here, but you probably should be able
to do:

bzr mv dir2/test.txt dir2/test2.txt --after

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuSW/UACgkQJdeBCYSNAANt0ACfQ8oFYVayeXsZCwdsDEjKsr7k
01gAoMWMbtggpQCzpF1dY8w92KQruQ77
=JAZ8
-----END PGP SIGNATURE-----

No this also doesn't work. You get the same error message in that case.

Shouldn't this bug be higher than medium importance? If you can't tell Bazaar that a file has moved the only option is to remove and add like subversion does. But this is defeating the whole benefit of Bazaar's rename support. I'm running into this bug quite often now and it's creating unnecessary conflicts as I have to mark files as deleted and re-added instead of moved.

On Sun, 2010-03-07 at 15:07 +0000, Nicholas Allen wrote:
> Shouldn't this bug be higher than medium importance? If you can't tell
> Bazaar that a file has moved the only option is to remove and add like
> subversion does. But this is defeating the whole benefit of Bazaar's
> rename support. I'm running into this bug quite often now and it's
> creating unnecessary conflicts as I have to mark files as deleted and
> re-added instead of moved.

Looks like a bug in 'bzr mv' to me.

I think this is a regression and we should fix it promptly - IDE's will
make life hell for people in this sort of situation.

 importance high

@Nicholas:

You've renamed dir to dir2, so you need:
  bzr mv dir2/test.txt dir2/test2.txt
not
  bzr mv dir/test.txt dir2/test2.txt

i.e. 'dir2' not 'dir' in the first argument.

We have a regression on the error message though, until bzr-1.17 it was:
  bzr: ERROR: Could not rename test.txt => test2.txt: dir/test.txt is not versioned.

where 'dir/text.txt' makes it a bit more apparent that 'dir2/test.txt' should be used.

I guess this makes sense and can confirm that doing this works. I was confused because the status says "dir/test.txt" has been removed and "dir2/test2.txt" is unversioned so I would expect that I can tell bazaar any file that it thinks is removed is actually renamed instead. After the directory rename shouldn't status show "dir2/test.txt" as removed? If the status uses the old dir name but mv expects the new dir name that feels a bit inconsistent to me.

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

Nicholas Allen wrote:
> Shouldn't this bug be higher than medium importance? If you can't tell
> Bazaar that a file has moved the only option is to remove and add like
> subversion does.

No, there other options:
1. use "bzr mv --auto", which will autodetect the move after the fact.
2. move the file to its old name, then use "bzr mv" to restore it to its
new name.

Aaron

This may have been fixed by some of the fixes to dirstate in late 2010. If anyone can still reproduce it, please attach a traceback.

This looks like bug 395556, but it was filed after that claimed to be fixed.

I can still reproduce this bug using the same sequence as Nicholas Allen. I can't reproduce bug 395556, so they don't seem to be related.

Bazaar (bzr) 2.2.5dev
  from bzr checkout C:/Users/me/Sources/bzr/bzr.2.2
    revision: 5134
    revid: <email address hidden>
    branch nick: bzr.2.2
  Python interpreter: C:\Users\me\Sources\bzr\myenv\Scripts\python.exe 2.6.6
  Python standard library: C:\Users\me\Sources\bzr\myenv\lib
  Platform: Windows-7-6.1.7601-SP1
  bzrlib: C:\Users\me\Sources\bzr\bzr.2.2\bzrlib
  Bazaar configuration: C:\Users\me\AppData\Roaming\bazaar\2.0
  Bazaar log file: C:\Users\me\Documents\.bzr.log

Tue 2011-07-12 16:03:51 +0200
0.118 bazaar version: 2.2.5dev
0.118 bzr arguments: [u'mv', u'dir/test.txt', u'dir2/test2.txt']
0.130 looking for plugins in C:/Users/me/AppData/Roaming/bazaar/2.0/plugins
0.190 looking for plugins in C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\plugins
0.216 encoding stdout as sys.stdout encoding 'cp850'
0.227 failed to load compiled extension: No module named _static_tuple_c
0.232 failed to load compiled extension: No module named _rio_pyx
0.237 failed to load compiled extension: No module named _dirstate_helpers_pyx
0.252 failed to load compiled extension: cannot import name _btree_serializer_pyx
0.260 failed to load compiled extension: No module named _chk_map_pyx
0.262 failed to load compiled extension: No module named _bencode_pyx
0.286 failed to load compiled extension: No module named _annotator_pyx
0.287 failed to load compiled extension: No module named _knit_load_data_pyx
0.293 failed to load compiled extension: No module named _known_graph_pyx
0.295 failed to load compiled extension: No module named _groupcompress_pyx
0.300 opening working tree 'C:/Users/me/Sources/bzr-bug'
0.318 attempting to move dir/test.txt => dir2/test2.txt
0.337 Traceback (most recent call last):
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\commands.py", line 912, in exception_to_return_code
    return the_callable(*args, **kwargs)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\commands.py", line 1112, in run_bzr
    ret = run(*run_argv)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\commands.py", line 690, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\commands.py", line 705, in run
    return self._operation.run_simple(*args, **kwargs)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\cleanup.py", line 135, in run_simple
    self.cleanups, self.func, *args, **kwargs)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\cleanup.py", line 165, in _do_with_cleanups
    result = func(*args, **kwargs)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\builtins.py", line 837, in run
    self._run(tree, names_list, rel_names, after)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\builtins.py", line 926, in _run
    tree.rename_one(src, dest, after=after)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\mutabletree.py", line 50, in tree_write_locked
    return unbound(self, *args, **kwargs)
  File "C:\Users\me\Sources\bzr\bzr.2.2\bzrlib\workingtree_4.py", line 1257, in rename_one
    WorkingTree.rename_one(self, from_rel, to_rel, after)
...