Comment 3 for bug 715000

Hi,

There is a chain of stacking

  A -> B -> C

(-> means stacked on).

We open A, which gets B as a fallback, which causes B to be opened which gets
C as a fallback.

We then try to get the known_graph of A, and we reach this code (groupcompress.py)

   def get_known_graph_ancestry(self, keys):
        """Get a KnownGraph instance with the ancestry of keys."""
        # Note that this is identical to
        # KnitVersionedFiles.get_known_graph_ancestry, but they don't share
        # ancestry.
        parent_map, missing_keys = self._index.find_ancestry(keys)
        for fallback in self._fallback_vfs:
            if not missing_keys:
                break
            (f_parent_map, f_missing_keys) = fallback._index.find_ancestry(
                                                missing_keys)
            parent_map.update(f_parent_map)
            missing_keys = f_missing_keys

So we are inside A.revisions, and we don't find the revision in our index, so we
look in the fallback, B.revisions, which doesn't have it either. If we looked in A.revisions
we would find it, but we don't.

Rob says:

<james_w> I would have assumed that most of this code didn't recurse at all call-sites, and just collected all the fallbacks when opening in to _fallback_vfs
<lifeless> each repo is mutable
<lifeless> so open is the wrong time
<lifeless> flattening at execution is probably appropriate
<lifeless> that or recursing via the public api

I am not going to work on this any further, so someone else should take it over
to stop Launchpad from OOPSing.

Thanks,

James