Internal error in bzr 1.5 when trying to resolve a conflict after rm'ing a directory.

[Christopher Burns]

When trying to resolve a conflict, one file appeared to be in two states, both 'removed' and 'unknown' in the 'bzr stat'. I removed the file with 'bzr rm --force FILE', then removed the parent directory (also a conflict). The next 'bzr stat' produced an internal error.

Attached is a script to reproduce the error with the public launchpad branches, and a full traceback.

Thanks!

[Christopher Burns (cburns)]

I found the correct way to resolve the conflict of this one file. bzr added the .THIS version of the file to the branch and I suspect my renaming and forced removed in the script was causing the fubar. That said, it seems odd that bzr added the .THIS to the branch, is this a bug? Not noticing this initially sent me on the wrong path.

Solution:

cburns@traits 12:34:21 $ bzr ls -v
? ctraits.c.BASE
V ctraits.c.THIS

cburns@traits 12:34:30 $ pwd
/Users/cburns/src/nipy-trunk/neuroimaging/utils/enthought/traits

cburns@traits 12:35:32 $ bzr rm ctraits.c.THIS
deleted neuroimaging/utils/enthought/traits/ctraits.c.THIS

cburns@traits 12:36:40 $ bzr resolve ctraits.c

cburns@traits 12:36:48 $ cd ..

cburns@enthought 12:37:29 $ bzr ls -v
V traits/

cburns@enthought 12:37:37 $ bzr rm traits/
deleted neuroimaging/utils/enthought/traits

cburns@enthought 12:37:48 $ bzr resolve traits

[Robert Collins (lifeless)]

Hi, this was probably caused by a merge from someone that had a file with unrelated ancestry and a different name, while you had removed your file - that would create a conflict like the one you saw.

I'm not sure there is a bug here, but perhaps we can think of some way to make the behaviour more transparent.