New bundle format; code structure

Sune Foldager cryo at cyanite.org
Mon May 23 09:16:39 CDT 2011


I'm currently looking at and thinking about the new bundle format. Not just the
format, but also how we'll implement it in the code. The current state of
affairs is a slight mess, as I wrote a mail about recently: sometimes full
bundles are used, often headerless ones. Sometimes there is compression,
sometimes not etc. I have tried to sum it up in the tables below:

Push:

proto    full bundle?    compression
http     yes             any (capability), unchunked
ssh      no              none, (streamed in 4k chunks)

Pull:

proto    full bundle?    compression
http     no              ext. zlib (4k chunks, 64k for decomp.)
ssh      no              none


Here "ext. zlib" means external zlib, as in: not being done by the bundler
(in general, not much bundle-related IS done by the two bundler classes..
they are a bit strange, really :p).

Since we're introducing a new argument for getbundle anyway, wouldn't it be
nicer if we could work towards something like this for pull:

Pull ng:

proto    full bundle?    compression
http     yes             any (capability/server's choice, chunked)
ssh      yes             any (capability/server's choice, chunked)

Default could then be zlib for http, none for ssh. Of course this will require
shuffling some code around, possibly enhancing the capabilities of the bundling
code and such, to ensure we can still do efficient chunked compressions and
decompressions. I have a vague idea in mind I could make more concrete.

For push, we need a new unbundle command (like getbundle; sendbundle?), and we
could perhaps "fix" ssh in that case as well, so we can unify it with http.

Thoughts on that?

Also, a draft of a new bundle format is here:
http://mercurial.selenic.com/wiki/BundleFormat2

It's rough, and Benoit had some comments (on irc), which I forgot. I tried to
include the following features:

- support for capabilities for future enhancements
- support for progress by including number of chunks for each changegroup
- support for deltaparent (for generaldelta)

Thoughts on that?

-Sune



More information about the Mercurial-devel mailing list