bidirectional graph caching

[Robert Collins]

I think it would offer some very nice performance benefits to have our
cached revisions graphs be bidirectional. I don't see a use case for the
file graphs or compression trees to be bidirectional at this point.

In particular to solve 'what revisions do I have to push' with a
stateless server, we have to spider out on a graph that the server
doesn't have. But the server may have some of it, and if it can start at
a revision we know it has (the last-revision of the branch being pushed
to), and walk towards children nodes in its local repository, we can use
the same latency reducing strategy of batching (or eventually even
streaming) the extant revision graph back to us. This allows a reduction
in round trips without having to upload as large requests (and given
common asymmetric last-mile links this is a good thing).	

Clearly we can get the network benefits in a crude fashion: load the
whole graph, invert it, then walk from the node we want to, but this
scales, well, terribly.

-Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080204/61b73d1d/attachment.pgp