making network performance 'good enough' for large projects
robertc at robertcollins.net
Tue Jan 15 01:21:50 GMT 2008
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
* 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
* /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
* 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
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080115/703712fa/attachment.pgp
More information about the bazaar