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

Peter Arrenbrecht peter.arrenbrecht at gmail.com
Mon Jun 6 08:13:11 CDT 2011


On Mon, Jun 6, 2011 at 1:03 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2011-06-06 at 00:36 +0200, Sune Foldager wrote:
>> On 2011-06-05 16:41, Matt Mackall wrote:
>> >On Sun, 2011-06-05 at 16:29 +0200, Sune Foldager wrote:
>> >> This is a just a light refactoring patch, but it's essentially a backout of:
>
> It comes down to this:
>
> I don't want to pass around naked file-like generators any more. You can
> tidy up and extend the current abstraction, or even offer a replacement
> abstraction, but the abstraction stays.

The split into localrepo and localproxy might help here.
localrepo.getbundle() might want to return a plain stream, or a
bundlestream that is basically passthrough stream, if you insist on a
wrapper type. And repoproxy.getbundle() could return the full-blown
unbundlestream. This on the assumption that you'd use a repoproxy when
you obtain a bundle from somewhere for local consumption, whereas
you'd get a bundle from localrepo to send elsewhere.

Maybe adding localrepo.getbundlestream() for the bundlestream directed
at bundle _writers_ might be even better. Then getbundle() can
continue to return unbundling support. Though I actually think it
should go away on localrepo as a public API. Folks should use
repoproxy to obtain bundles.

-parren


More information about the Mercurial-devel mailing list