bzr status -c tip:N crashes

[Eli Zaretskii]

I can reproduce this crash in any bzr branch. The example below is from bzr-tiplog's own trunk. As can be seen, bzr correctly displays the files affected by the referenced revision, but then crashes:

D:\usr\eli\bzr\bzr-tiplog>bzr status -c tip:1
modified:
  __init__.py
  log.py
bzr: ERROR: exceptions.AttributeError: 'InventoryRevisionTree' object has no att
ribute 'branch'

Traceback (most recent call last):
  File "bzrlib\commands.pyo", line 923, in exception_to_return_code
  File "bzrlib\commands.pyo", line 1128, in run_bzr
  File "bzrlib\commands.pyo", line 676, in run_argv_aliases
  File "bzrlib\commands.pyo", line 698, in run
  File "bzrlib\cleanup.pyo", line 135, in run_simple
  File "bzrlib\cleanup.pyo", line 165, in _do_with_cleanups
  File "bzrlib\commands.pyo", line 1145, in ignore_pipe
  File "bzrlib\builtins.pyo", line 311, in run
  File "bzrlib\status.pyo", line 225, in show_tree_status
  File "C:/Program Files/Bazaar/plugins\loom\__init__.py", line 101, in show_loo
m_summary
AttributeError: 'InventoryRevisionTree' object has no attribute 'branch'

bzr 2.5b4 on python 2.6.6 (Windows-XP-5.1.2600-SP2)
arguments: ['bzr', 'st', '-c', 'tip:1']
plugins: bisect[1.1.0dev], bzrtools[2.4.1], changelog_merge[2.5b4],
    colo[0.3.1dev], encdiff[1.0.0], explorer[1.1.0], fastimport[0.12.0dev],
    git[0.6.6dev], grep[0.4.0], history_db[unknown], keywords[unknown],
    launchpad[2.5b4], loom[2.2.1dev], netrc_credential_store[2.5b4],
    news_merge[2.5b4], pipeline[1.1.0], qbzr[0.18.6], rewrite[0.6.3dev],
    svn[1.1.1], tiplog[0.0.5dev], upload[1.0.1dev], xmloutput[0.8.8]
encoding: 'cp1255', fsenc: 'mbcs', lang: None

*** Bazaar has encountered an internal error. This probably indicates a
    bug in Bazaar. You can help us fix it by filing a bug report at
        https://bugs.launchpad.net/bzr/+filebug
    including this traceback and a description of the problem.

[Brian de Alwis (slyguy)]

I don't think this is a tiplog problem but more a loom problem, since tiplog doesn't appear in the backtrace. You can probably trigger it by:

   $ bzr tiplog --show-ids
   $ bzr status -c XXXX

where XXXX is the corresponding revid to tip:1.
`
I don't know how loom works exactly, but my guess is that a change to a loom may result in a number of commits underneath the hood. With tiplog's current implementation, each of those intermediate commts will be recorded separately. And it may well be that loom's internal structure isn't meant to answer 'status' type queries.

I have a merge proposal to add bzr command-level hooks, so that tiplog can log tip changes based on semantically-meaningful boundaries. That should avoid this type of error.

[Eli Zaretskii (eliz)]

You are right, the problem is in loom. But the problem has nothing to do with changes to a loom, as I don't use looms in any of the branches I tried this with. So my guess is that this is a generic bug in loom that raises its ugly head each time "status" is invoked with a range of revisions.

I have filed another bug report about that, https://bugs.launchpad.net/bzr/+bug/904095. Feel free to close this one.