"bzr gcommit" issues an exception

[Mats Kindahl]

From <https://bugs.edge.launchpad.net/bzr-gtk/+bug/279831/comments/6>

I got the same error as Guilhem:

What I did to get it was:
- Branch a tree (mysql-6.0)
- Merge with another tree (mysql-5.1-maria) with bzr merge --weave
- Fixed merge issues, did make and make test to verify tre
- bzr resolved --all
- bzr gcommit

I am now stuck and can't continue developing until this is fixed.
Please prioritize this bug accordingly (we have a support contract with Canonical)

bzr status output looks sane (it completes with no errors or warnings(

I am using bzr version 1.8 and gtk plugin 0.96.0dev1
I applied the gtk-fix.patch [that fixes bug 279831], but it didn't help; Now I get another error instead.

Here is the output from bzr gcommit after the patch was applied:

(/my/mysql-6.0-maria-tmp) bzr gcommit
bzr: ERROR: exceptions.AssertionError:

Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 849, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 795, in run_bzr
    ret = run(*run_argv)
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 495, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/monty/.bazaar/plugins/gtk/__init__.py", line 394, in run
    dlg = CommitDialog(wt)
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 121, in __init__
    self.fill_in_data()
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 135, in fill_in_data
    self._fill_in_files()
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 193, in _fill_in_files
    ) in iter_changes_to_status(self._basis_tree, self._wt):
  File "/home/monty/.bazaar/plugins/gtk/diff.py", line 659, in iter_changes_to_status
    assert kinds[0] is not None
AssertionError

bzr 1.8 on python 2.5.1 (linux2)
arguments: ['/usr/local/bin/bzr', 'gcommit']
encoding: 'ANSI_X3.4-1968', fsenc: 'ANSI_X3.4-1968', lang: 'C'
plugins:
  difftools /home/monty/.bazaar/plugins/difftools [0.91.0]
  extmerge /home/monty/.bazaar/plugins/extmerge [unknown]
  gtk /home/monty/.bazaar/plugins/gtk [0.96.0dev1]
  launchpad /usr/local/lib/python2.5/site-packages/bzrlib/plugins/launchpad [unknown]
  multiparent /usr/local/lib/python2.5/site-packages/bzrlib/plugins/multiparent.py [unknown]
*** Bazaar has encountered an internal error.
    Please report a bug at https://bugs.launchpad.net/bzr/+filebug
    including this traceback, and a description of what you
    were doing when the error occurred.

Here is the associated output from .bzr.log

0.042 encoding stdout as sys.stdout encoding 'ANSI_X3.4-1968'
0.044 bzr arguments: [u'gcommit']
0.044 looking for plugins in /home/monty/.bazaar/plugins
0.234 importmbox not available unless bzrtools is installed
0.274 looking for plugins in /usr/local/lib/python2.5/site-packages/bzrlib/plugins
0.275 Plugin name __init__ already loaded
0.275 Plugin name gtk already loaded
0.275 Plugin name __init__ already loaded
0.278 looking for plugins in /usr/lib/python2.5/site-packages/bzrlib/plugins
0.308 encoding stdout as sys.stdout encoding 'ANSI_X3.4-1968'
1.138 opening working tree '/home/my/mysql-6.0-maria-tmp'
10.902 Traceback (most recent call last):
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 849, in run_bzr_catch_errors
    return run_bzr(argv)
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 795, in run_bzr
    ret = run(*run_argv)
  File "/usr/local/lib/python2.5/site-packages/bzrlib/commands.py", line 495, in run_argv_aliases
    return self.run(**all_cmd_args)
  File "/home/monty/.bazaar/plugins/gtk/__init__.py", line 394, in run
    dlg = CommitDialog(wt)
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 121, in __init__
    self.fill_in_data()
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 135, in fill_in_data
    self._fill_in_files()
  File "/home/monty/.bazaar/plugins/gtk/commit.py", line 193, in _fill_in_files
    ) in iter_changes_to_status(self._basis_tree, self._wt):
  File "/home/monty/.bazaar/plugins/gtk/diff.py", line 659, in iter_changes_to_status
    assert kinds[0] is not None
AssertionError

10.906 return code 4

[Andrew Bennetts (spiv)]

This appears to a duplicate of bug 279831: the traceback and assertion are the same as the original report in 279831.

Did you mean to file a bug for the different exception in the comment by Michael Widenius <https://bugs.edge.launchpad.net/bzr-gtk/+bug/279831/comments/6> instead?

[Mats Kindahl (mkindahl)]

Andrew Bennetts wrote:
> This appears to a duplicate of bug 279831: the traceback and assertion
> are the same as the original report in 279831.
>
> Did you mean to file a bug for the different exception in the comment by
> Michael Widenius <https://bugs.edge.launchpad.net/bzr-
> gtk/+bug/279831/comments/6> instead?

That was the intention, yes.

Sorry about that,
Mats Kindahl
--
Mats Kindahl
Lead Software Developer
Replication Team
MySQL AB, www.mysql.com

[John A Meinel (jameinel)]

So... I think this is actually triggered from doing:

touch foo
bzr add foo
rm foo

bzr gcommit

  File "C:\Users\jameinel\dev\bzr\plugins\gtk\diff.py", line 659, in iter_changes_to_status
    assert kinds[0] is not None
AssertionError

I can reliably trigger it using that sequence. The problem is that we have a versioned file which appears to be missing. So the 'source' kind is None because it was just added, but the target kind is None because the file has been removed.

I don't know the correct fix for bzr-gtk, but in the mean-time you can do "bzr rm foo" to fix this.

However, finding out what "foo" is actually hanging is a bit difficult, because it won't show with 'bzr status" (because it sees (None, None) as no change.)

You *can* do: bzr commit -m "find the bogus file"

Which will include a line:
missing foo

And then if you don't want that commit, you can do:
bzr uncommit
bzr rm foo

(Actually in my testing here, doing 'bzr commit --local' caused an abort because there were no effective changes, and cleaned out the unused entry.)

[John A Meinel (jameinel)]

Some further comments:

The only command I've found so far that shows the file is 'bzr inventory'. So you can do

bzr inventory > ../current.txt
bzr inventory -r -1 > ../last.txt
diff -u ../last.txt ../current.txt

Which will show you what file is present that needs to be 'bzr rm' to get back into proper working order.

I'm not really sure how 'bzr gcommit' should handle these entries... It could try to present it as a missing file, I guess.

[Vincent Ladeuil (vila)]

The only way I found to reproduce this bug so far it by issuing:
   bzr resolve --all
in a tree containing (among other test conflicts) Contents conflicts.

gcommit then receives non-sensical entries from iter_changes() where both kind are None, which I read as a file which was not versioned and is now not versioned, which by definition shouldn't appear in the output of iter_changes()...

Investigation continues.

[Andrew Bennetts (spiv)]

I've updated the description to match the bug Mats meant to file (and to match the bug we're actually discussing here!).

[Vincent Ladeuil (vila)]

The attached script reproduces the bug in a simpler way.

The root problem is really to commit files that were involved in a conflict resolution. 'commit' knows how to handle them but not 'gcommit'.

I'm working on a fix.

[Vincent Ladeuil (vila)]

FIx available in the associated branch, waiting for review.

[GuilhemBichot (guilhem-bichot)]

I tested again, with the latest bzr-gtk, and the same problematic merge, and it now commits ok. Thanks!
Here's an interesting snippet from what gcommit printed:

Committing to: /home/mysql_src/tmp/monty/repo/retest/mysql-6.0-maria-tmp/
missing .bzr-mysql.moved
modified .bzrignore
modified configure.in
missing server-tools

What are the "missing" lines? Note that John mentioned some "missing" files in his previous posts.

[GuilhemBichot (guilhem-bichot)]

and... should "bzr commit" and "bzr gcommit" fail (with an informative message) when they found "missing" files?

[John A Meinel (jameinel)]

'missing' means that the file is marked as versioned, but is not present on disk. At the moment they are scheduled for automatic removal.

It has been discussed whether that is the "best" way, but there is enough disagreement that we are left with status quo. (I'm personally in favor of failing commit if there is something "missing" unless a flag is set, especially now that plain "bzr rm" marks missing things as unversioned.)

[Mikael Ronstrom (mikael-ronstrom)]

Hi,
In this case failing with a report of why had been the appropriate
action. I can't even recall adding the files which was now missing.
So reporting this as an error had been appropriate, now I found it
on a slightly longer path :)

Rgrds Mikael

John A Meinel wrote:
> 'missing' means that the file is marked as versioned, but is not present
> on disk. At the moment they are scheduled for automatic removal.
>
> It has been discussed whether that is the "best" way, but there is
> enough disagreement that we are left with status quo. (I'm personally in
> favor of failing commit if there is something "missing" unless a flag is
> set, especially now that plain "bzr rm" marks missing things as
> unversioned.)
>