[PATCH] httpclient: update to 07d8c356f4d1 of py-nonblocking-http
mpm at selenic.com
Thu Oct 20 11:51:55 CDT 2011
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
And they're just that: implementation problems. We can fix them. But
there are other problems that are significantly more fundamental. For
- 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". 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.
 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.
More information about the Mercurial-devel