graphs and the smart server

[Robert Collins]

One of the challenges with the smart server is avoiding passing full
graphs over the wire: For large repositories the full graph is huge, and
a dominating factor on incremental push and pulls.

I've put together the basic logic to allow using a number of different
routines to build up a description of the revisions needed e.g. for log,
pull, etc.

At a design level the idea is to let the server provide an
opaque-to-the-client description of the graph, and a list of revisions
that the client should indicate local presence or absence of. This is
then used to refine the graph.

This approach can emulate the branch-point based routine that hg uses,
or a very dag-aware scheme equally. The initial approach I mocked up
does much better than pulling the knit index, for a bzr sized history.

I propose that we add a __iter__ method to Graph which will allow Graph
to be used as the input to various repository methods; then with an
InterRepository specialisation for to/from RemoteRepository, we can
transparently kick in this remote negotiation logic.

Current prototype/demo code is in two parts:
remote graph: sftp://bazaar.launchpad.net/~bzr/bzr/remotegraph
'netsim' plugin: http://bazaar.launchpad.net/~lifeless/+junk/bzr-netsim



Cheers,
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/20070507/9090bc99/attachment.pgp