Comment 10 for bug 388269

We looked a bit at it, and I think there 2 things going on with the bug.

1) The bit I fixed, which is with a single branch, walking most of its ancestry whenever we ask for more data from the remote server.

2) With a *stacked* configuration. We end up asking the stacked branch "do you have X" it replies "no", then we go to the fallback repository and ask "do you have X", and it replies "yes, X=>Y, Y=>Z, Z=>A". Then we step to Y, and *ask the stacked repository* "Do you have Y", and it says "No", so then we go to the fallback repository and find it in the cache, going to Z. etc.

So basically, we have a read-ahead cache but the 'cache' only exists for the fallback, and we only ask the fallback after we've asked the stacked repository if it knows anything.

The fix basically seems that we just need to expose the fallback cache up to a higher level. Something along the lines of:

a) Stacked: Do you have X in your cache? (No)
b) Fallbacks: Do you have X in your cache? (No)
c) Stacked: RemoteCall Do you have X? (No)
d) Fallbacks: RemoteCall Do you have X? (Yes, and here is more stuff for the cache)

Or combine the cache somehow. Or notice that when we found X it was from the fallback repository, so search for Y there first (locality).