Smart revision fetching update

[Robert Collins]

On Thu, 2007-08-09 at 16:27 +1000, Andrew Bennetts wrote:
> 
> 
>   * Add a specialised smart method for the initial pull case.  At the
> moment
>     with my code the initial pull of a branch retrieves the branch's
> ancestry,
>     and then sends a big Repository.fetch_revisions call explicitly
> listing
>     every revision.  So for branching bzr at the moment it would send
> over 12000
>     revision IDs across the wire, the same ones it just downloaded.
> So probably
>     I'll add a “Repository.fetch_all_revisions” smart request that
> just takes
>     the tip revision ID instead.  This will make this code a strict
> improvement
>     over the current tarball hack. 

Can I suggest a different approach? When I was experimenting with graph
deltas, I put together a cheap hack - so I'm not suggesting you use it -
rather use the idea.

The idea was that 'get_revision_graph/get_ancestry etc etc' method calls
on a smart server does not return the literal contents, rather it
returns a description about the contents.

e.g. say you ask for the ancestry of revision X, where X is the branch
tip. Rather than returning 12K revisions, you can return
([X], []) - meaning 'all nodes from the heads 'X', cutting the graph at
no nodes.

This would be an object locally - I used the Graph object when I did
this, but that object has been deprecated.

Then this result can be passed into a method such as fetch. At that
point one of two things will happen:
 - local iteration will be done. This will trigger a smart server method
to resolve the contents of the this graph description.
 - an InterRepository call will be made where one end is the smart
server repository that provided the description. In this case the
description is sent back over the wire, *not* the full list of
revisions.

Also, one could create this description - the graph from X - locally and
avoid a round trip here - while still having __iter__ resolve the
contents if needed.

This would avoid special casing initial pull, and allow incremental
pulls to be more efficient too.

-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/20070809/9d6eeefb/attachment.pgp