[PATCH 2 of 2] Fix income/pull with bundle and -R (issue 820)

Matt Mackall mpm at selenic.com
Tue Dec 4 12:41:21 CST 2007


On Tue, Dec 04, 2007 at 09:06:37AM +0100, Peter Arrenbrecht wrote:
> On Dec 4, 2007 8:51 AM, Matt Mackall <mpm at selenic.com> wrote:
> >
> > On Tue, Dec 04, 2007 at 07:25:56AM +0100, Peter Arrenbrecht wrote:
> > > On Dec 3, 2007 10:53 PM, Matt Mackall <mpm at selenic.com> wrote:
> > > > On Mon, Dec 03, 2007 at 08:49:35PM +0100, Peter Arrenbrecht wrote:
> > > > > +import changegroup, util, os, struct, bz2, tempfile, mdiff, hg
> > > >
> > > > I think that'll give us a circular include, which becomes problematic
> > > > when demandloading is disabled. Ugh.
> > >
> > > So we go with the additional field in the ui class, then?
> >
> > Yeah, it at least won't have that problem. But it'll be an ugly
> > layering violation. I'm tempted to say use setconfig("bundle","base").
> 
> How would "use setconfig("bundle","base")" be less of a layering
> problem than a new field?

It isn't, it just looks less like one.

The real problem is that -bundlerepos- are the layering violation in
the current architecture. No two repo objects should need to know
about each other's internals directly. That's a good thing. It forces
everything to go through the wire protocol for one thing. But a
bundlerepo intrinsically needs to know about the main repo because
it's incomplete.

Up until now bundlerepos have just been -guessing- where their base
repo is, so eventually we'll have to introduce something gross like a
ui hack or a global variable or bite the bullet and say "yes, it
generally makes sense for the second repo in an operation to be able
to poke at the interals of the first repo."

So what's the value of making it -look- like less of layering
violation? Basically, it keeps the ui class from growing barnacles.

And it's really not so bad: we use setconfig to turn other command
line options into config settings already. If we think of -R as just
an alias for our weird config option, we can rationalize this pretty
well.

-- 
Mathematics is the supreme nostalgia of our time.


More information about the Mercurial-devel mailing list