LookupError, <file> not found in manifest

[mike_mp@…]

Traceback:

Traceback (most recent call last):
  File "/Users/classic/Desktop/tmp/Trac-0.12.2/trac/web/main.py", line 511, in _dispatch_request
    dispatcher.dispatch(req)
  File "/Users/classic/Desktop/tmp/Trac-0.12.2/trac/web/main.py", line 237, in dispatch
    resp = chosen_handler.process_request(req)
  File "/Users/classic/Desktop/tmp/Trac-0.12.2/trac/versioncontrol/web_ui/browser.py", line 390, in process_request
    dir_data = self._render_dir(req, repos, node, rev, order, desc)
  File "/Users/classic/Desktop/tmp/Trac-0.12.2/trac/versioncontrol/web_ui/browser.py", line 549, in _render_dir
    entries = [entry(n) for n in node.get_entries()
  File "/Users/classic/Desktop/tmp/mercurial-plugin/tracext/hg/backend.py", line 1026, in get_entries
    str_entries)
  File "/Users/classic/Desktop/tmp/mercurial-plugin/tracext/hg/backend.py", line 956, in find_dirctx
    dr = max(dr, max_ctx.filectx(f).linkrev())
  File "/Users/classic/Desktop/tmp/lib/python2.7/site-packages/mercurial/context.py", line 177, in filectx
    fileid = self.filenode(path)
  File "/Users/classic/Desktop/tmp/lib/python2.7/site-packages/mercurial/context.py", line 166, in filenode
    return self._fileinfo(path)[0]
  File "/Users/classic/Desktop/tmp/lib/python2.7/site-packages/mercurial/context.py", line 161, in _fileinfo
    _('not found in manifest'))
LookupError: lib/sqlalchemy/databases/postgresql.py@58937c3f4abe: not found in manifest

Error appears in Trac 0.12 with Mercurial plugin r10879.

The error is be observed by linking Trac to the SQLAlchemy repository at ​http://hg.sqlalchemy.org/sqlalchemy/ , however I have a suspicion that the issue may be related to the latest revision being against a named branch that's not the "default". The error occurs when navigating to "lib/sqlalchemy/" as well as "test/perf", and probably others.

The only similar error I could find was #9611, but I don't have the same thing here as my Mercurial is reporting the version correctly:

classics-MacBook-Pro:mercurial-plugin classic$ ../bin/python
Python 2.7.2 (v2.7.2:8527427914a2, Jun 11 2011, 15:22:34) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from mercurial import __version__
>>> __version__.version
'2.0.1'

A patch which seems to resolve the issue, though is probably not the right way to go as it's just silently squashing the error:

tracext/hg/backend.py

@@ -953 +953 @@
                     str_files = str_entries[str_dir]
                     dr = str_dirctxs.get(str_dir, 0)
                     for f in str_files[:k]:
-                        dr = max(dr, max_ctx.filectx(f).linkrev())
+                        try:
+                            dr = max(dr, max_ctx.filectx(f).linkrev())
+                        except LookupError:
+                            pass
                     str_files = str_files[k:]
                     if str_files:
                         str_entries[str_dir] = str_files

This error did not occur in Trac .11 with the older version of the plugin. I tried working backwards through TracMercurial revs but the earliest rev that even works with 0.12 seems to be r10698 which also has the issue.

[rblank]

Thanks for the very detailed bug report!

[cboos]

Problem reproduced with Hg 2.0+20111103 but also with 1.8.4 so it's probably our fault ;-)

---

[OT] we did some simultaneous changes again ;-) ⇒ #7145

[cboos]

Ok, so at @7871, when it switches to the "filelog" strategy, the files it is looking for are simply not there… which can happen of course if @7871 is on a different branch than from where we started from.

So yes, the proper way is to simply ignore the error and move on.
The patch indeed works fine, thanks!

[cboos]

Applied in r10898 for the 0.12 version and r10898 for the 0.13 version.

Whether the current approach of looking at all the past revisions one by one is adequate or not is another story… If we were to "stay" on a branch and only looking at the previous revision, we would perhaps have a more coherent view (such a bug would have been avoided), the browsing would certainly be even faster, but maybe we would have a slightly less useful view, as you wouldn't see in one place the "recent" activity that happened across several branches. Currently, if you browse Dir/ on branch A, you could see things like Dir/A modified "two days ago" on branch A, Dir/B modified "three days ago" on branch B. If we stayed on A, Dir/B would possibly show "modified ten months ago"…

So it's a trade-off, and maybe a browsing option would be useful here.