[PATCH] httpclient: update to 07d8c356f4d1 of py-nonblocking-http

[Matt Mackall]

On Thu, 2011-10-20 at 15:46 +0200, Angel Ezquerra wrote:
> On Thu, Oct 20, 2011 at 2:52 PM, Martin Geisler <mg at aragost.com> wrote:
> > Matt Mackall <mpm at selenic.com> writes:
> >
> >> On Mon, 2011-10-17 at 22:39 +0200, Martin Geisler wrote:
> >>> You write that we should not bundle py-nonblocking-http inside the
> >>> Mercurial repository itself. Instead we should make
> >>>
> >>>   mercurial-and-dependencies/
> >>>     Makefile <- whatever glue logic is required
> >>>     mercurial/ <- our current repo, without the httpclient/
> >>>     py-nonblocking-http/ <- your current repo, as is
> >>>
> >>> That sound good to me and to acknowledge point that I wrote that we
> >>> could make a "super" repo.
> >>
> >> (Yes, you're right, you did acknowledge this piece of the argument.
> >> Sorry. But I also wrote why I didn't think this was a good idea in my
> >> original email on the subject.)
> >
> > Yes, such a build repo is unnecessary and there are better ways to solve
> > the dependency on py-nonblocking-http than using subrepos. I'm not
> > trying to argue that subrepos are necessary here :)
> >
> >> I'm going to take you all the way back to my original counter-argument:
> >>
> >> - Subrepos are inherently suboptimal.
> >> - Using subrepos when you don't HAVE TO is a bad idea.
> >> - We do not have a compelling reason to use subrepos.
> >> - Ergo we would be setting A BAD EXAMPLE for users by doing it anyway.
> >>
> >> What is more important, dogfooding or setting a good example?
> >
> > I think I feel that dogfooding is more important in this case. As simple
> > as that. I'm okay with not using subrepos for Mercurial -- not using
> > them makes my life easier too...
> >
> >> I feel like most of the people I see trying to use subrepos are
> >> incredibly ill-advised. They do it because that's how they did it in
> >> SVN and they know so little about how Mercurial works when they start
> >> that they never properly understand the alternatives and trade-offs.
> >> And then they discover that subrepos are a huge pain in the ass and
> >> they think "wow, this sucks".
> >
> > You're right -- many things would be solved much better by using a tool
> > like an artifact repository.
> 
> That is true, as far as subrepos work _today_, but I don't think there
> is a reason why things could not be improved to a point where this is
> no longer true in many cases.
> 
> In fact, once you understand why you should always use relative
> subrepos (unless you have a very good reason not to), then a lot of
> the problems and confusion that people have with subrepos disappear.

There are a bunch of implementation problems:

- commit recursion
- path difficulties
- cornercases with merge
- etc.

And they're just that: implementation problems. We can fix them. But
there are other problems that are significantly more fundamental. For
instance:

- pull doesn't pull subrepos

People quite naturally expect pull to recurse, but it turns out it's not
well-defined. And I mean that in the mathematician's sense of "there is
no logically consistent way to do that"[1]. It is impossible to make
this work in a way that seamlessly matches core Mercurial. Thus there
will ALWAYS be an "expectation pitfall" here because of the intrinsic
mismatch between core Mercurial and subrepos.

[1] Dear reader, please don't make me repeat the arguments, instead go
read the list archives and the explanation on the wiki and think about
it a while.

-- 
Mathematics is the supreme nostalgia of our time.