Traceback error browsing Mercurial repository

[james@…]

I'm getting the following traceback error when attempting to use the repository browser to browse one repository. The two others I tested worked correctly.

Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/api.py", line 436, in send_error
  File "build/bdist.linux-x86_64/egg/trac/web/chrome.py", line 844, in render_template

... snip 28 calls (genshi stuff) ...

  File "/usr/lib/python2.4/site-packages/genshi/template/eval.py", line 178, in evaluate
    return eval(self.code, _globals, {'__data__': data})
  File "/var/www/.python-eggs/Trac-0.12-py2.4.egg-tmp/trac/templates/error.html", line 165, in <Expression u'shorten_line(repr(value))'>
    <td><code>${shorten_line(repr(value))}</code></td>
  File "/usr/lib64/python2.4/site-packages/mercurial/context.py", line 37, in __repr__
    return "<changectx %s>" % str(self)
  File "/usr/lib64/python2.4/site-packages/mercurial/context.py", line 31, in __str__
    return short(self.node())
  File "/usr/lib64/python2.4/site-packages/mercurial/context.py", line 100, in node
    return self._node
AttributeError: 'changectx' object has no attribute '_node'

I've recently migrated from subversion to mercurial. As part of the migration I split the original repository into two parts. The second repository is simply a useful subset of the other, made by cloning only the default branch and two recent release branches. (This helps to control the size of clones, and is a technique borrowed from Python's recent migration.)

So far, I've had no trouble accessing this repository using any of the hg command line, hgweb, and TortoiseHg.

The above error is seen when I try to browse the subset repository. This system is currently running Trac 0.12, TracMercurial 0.12.0.28dev-r10653, and Mercurial 1.8.3 all running on CentOS 5.3.

[Christian Boos]

This traceback is a secondary error, triggered during the error reporting of the original error. The Trac log file should contain this original error.

In case the problematic repository is public, please mention the clone URL so that we can try to reproduce the issue.

[Remy Blank]

It also seems to indicate a bug in Mercurial, as the error happens while doing a repr() of a changectx object, which seems to be supported.

[James Emerton <james@…>]

Here's the error from the trac log:

Traceback (most recent call last):
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 513, in _dispatch_request
  File "build/bdist.linux-x86_64/egg/trac/web/main.py", line 235, in dispatch
  File "build/bdist.linux-x86_64/egg/trac/versioncontrol/web_ui/browser.py", line 399, in process_request
  File "build/bdist.linux-x86_64/egg/tracext/hg/backend.py", line 615, in get_quickjump_entries
  File "/usr/lib64/python2.4/site-packages/mercurial/localrepo.py", line 206, in __getitem__
    return context.changectx(self, changeid)
  File "/usr/lib64/python2.4/site-packages/mercurial/context.py", line 27, in __init__
    self._node = self._repo.lookup(changeid)
  File "/usr/lib64/python2.4/site-packages/mercurial/localrepo.py", line 551, in lookup
    raise error.RepoLookupError(_("unknown revision '%s'") % key)
RepoLookupError: unknown revision '4234c55b21044a7dce54bbfd81260147ca33b32f'

By my reading of this, tracext.hg.backend.get_quickjump_entries is enumerating the .hgtags file and trying to fetch information about a revision I have omitted from this clone. It appears as though the fix is just to suppress RepoLookupError and continue with the next tag.

[James Emerton <james@…>]

Ignore RepoLookupError while examining tags

[Christian Boos]

Great! Patch applied in r10692 and r10693.

It seems that RepoLookupError is only available starting with Mercurial 1.4. I verified that using RepoLookupError in the except is not a problem even if the symbol is not really defined (the import always succeed due to the demandimport mechanism), but I didn't verify what other exception was raised with old versions in the same situation. Well, most people are probably using newer versions anyway.

I'll leave the ticket open for now as a reminder to check what was up with this repr issue. Eventually we should even use a safe_repr in the error reporting code that would catch and display any such secondary error.

[Christian Boos]

Follow-up to 4:

I'll leave the ticket open for now as a reminder to check what was up with this repr issue. Eventually we should even use a safe_repr in the error reporting code that would catch and display any such secondary error.

safe_repr added in r10940.