making network performance 'good enough' for large projects

[Robert Collins]

I've created a list of some things that need to be done for making bzr
acceptable for really large projects over the network. I thought I'd put
it out there for debate - have I missed essential things? wrong
approaches? etc?

 * Deciding how to benchmark network performance - I've blogged for a
lazyweb response - because fully automated benchmarks are good, but not
worth paying a lot of time for at this point. The lazyweb responses
suggested NetEm overwhelmingly.

 * Stacked branches:
   These can allow uploading new branches anywhere, that only contain
   the new work that is in the branch - about the same size as a bundle.
   Deps: No specific dependencies

 * pack streaming format
   dependencies: streaming push
   Current streaming formats use a format that requires large buffering
   on pack repositories; e.g. can upload multiple ISO's safely.

 * SearchRecipe API on smart server 'get revision' api's: allow
   requesting many revisions without large uploads.
   We're done when requesting a full new branch does not require the
   client to upload the entire set of revisions to be downloaded.
 
 * New delta logic: halves storage size, reduces network bandwidth on
   initial pull by 50%
   dependencies: pack streaming capability (gives the network format
                 versioning needed to rev sensibly)
   We're done when there is a stable format with the delta styles 
   dicussed by John/Aaron on the bzr list; which works with the smart
   server streaming push and pull.
   
 * streaming push with bzr+ssh: Get pushing pushing revisions to use a
   single stream of data to the server rather than direct file like
   repository access

 * /solid/ switch support: reduce the cost of new branches for 'C style'
   languages (those with expensive compile processes).
   We're done when there is an easy (1 command, 2 at most) way to make
   a new branch and switch a local working copy over to working on it in
   bzr core.

 * end to end pull optimisation

 * end to end push optimisation

-- 
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/20080115/703712fa/attachment.pgp