[PATCH 0 of 9] Move and refactor bundling logic

Matt Mackall mpm at selenic.com
Thu Feb 14 14:45:51 CST 2013


On Thu, 2013-02-14 at 20:40 +0100, Sune Foldager wrote:
> Benoit and I worked on this at the sprint, following the bundle format 2
> discussion. It takes some first steps towards implementing the new format.
> It basically moves all bundle creation logic out of localrepo.py and into
> changegroup.py, into the bundler10 class.
> 
> The patch queue is posted as-is for easier review, although it may need some
> work before push. Moving forwards from this, I think the plan is something
> like the following:
> 
> I'd like to do a dev spike on creating a new bundle format, ignoring some
> details such as we haven't decided on some specifics about how to encode hunk
> types, lengths etc. I think (but Benoit and I don't entirely agree) it would
> be best to put that into a new bundler20 (or whatever) class, which derives
> from bundler10. A factory would then be needed to return the correct bundler.

That more or less matches my vision. It's why there's a version number
on the existing class.

> I think that keeping it in the same class, will cause a lot of clutter, a lot
> of if newbundleformat: in many places, and make the code harder to follow.

In particular, it should be possible to unconditionally do stuff like:

  bundler.addbookmarkchunk(...)  # or whatever new feature

..and if the bundle version being used doesn't support it, silently
no-op.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list