collections of revision ids

Robert Collins robertc at robertcollins.net
Fri Jan 11 02:07:08 GMT 2008


So in order to reduce network traffic during pull with a smart server I
want a way to describe a set of revisions that does not involve listing
them all.

This is needed in the local client codebase for code reuse - we often
generate collections of revision ids by doing the same basic search -
e.g. lca, leftmost_difference.

So I'm thinking of something like a 'Searchrecipe' object or possibly
just an extension to the breadth first searcher. (though I think the
concept is more general and don't really want to have to have multiple
inheritance on the searcher objects themselves).

So the idea is that a new version of the 'RemoteRepository.fetch' verb
will take a SearchRecipe as a parameter. The SearchRecipe will have:
 - start_revisions
 - exclude_revisions

and thats it.

Locally, when we do a graph walk to figure out what revisions to fetch
(with find_ghosts=False), we create a SearchRecipe with the start node
of our search. And each time we stop searching a node, we add that to
the exclude_revisions set.

Then when the remote server is given the recipe it can repeat it
exactly, without the client's graph data, and derive the correct set of
revisions to send to the client.

The only race condition I can think of is a ghost filling on the server
occuring after the client searched, for a revision the client has. We
can avoid that by cross checking the found revisios - e.g. by adding a
count field, or a checksum.

-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/20080111/c31ecf82/attachment.pgp 


More information about the bazaar mailing list