[PATCH 0 of 1] RFC: bundle code path refactoring

Sune Foldager cryo at cyanite.org
Sun Jun 5 09:29:54 CDT 2011

This is a just a light refactoring patch, but it's essentially a backout of:

changeset:   12343:6a6149487817
user:        Matt Mackall <mpm at selenic.com>
date:        Mon Sep 20 14:32:21 2010 -0500
summary:     bundle: encapsulate all bundle streams in unbundle class

I don't know the reason for the above changeset, though, and it doesn't have
a longer description or comments to clarify it. I'll elaborate on my reasons:

In order to move towards a more unified wire format for bundles, we'd like to
transfer "full" (i.e. with format header) bundles for pull (changegroup(subset)
and getbundle). We already do this for push on http, and push on ssh also
accepts it in newer code, although we don't have a capability and thus don't
use it.

The unbundler (unbundle10) is used to parse the bundle format. It also does
on-the-fly decompression of the stream, if the bundle is compressed. Without
the present patch we will not be able to use compressed bundles in the new
wire commands. Note that we currently never do so, instead relying on a
compression wrapper on top of the data.

Wrapping a stream which is only used as a stream in something called an
unbundler seems wrong to me, and complicates things a lot when you throw
compression into the mix. So I'd like to remove it.

The longer term plan is roughly something like this:

1. Make the unbundler able to deal with full bundles (essentially by moving the
   code from readbundle to the unbundler).
2. Make small changes to the bundle generators (in localrepo and group in
   revlog), to enable them to transparently produce compressed bundles. This
   will be handled by the bundlehelper (bundle10 class; I hesitate to call it
   a bundler, since it plays a relatively minor role in the bundle format).
3. The new wire commands (or extended existing commands) can now use these
   bundles instead of the current wrapped-compression, if we want to.


More information about the Mercurial-devel mailing list