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

[Martin Geisler]

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.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://mercurial.aragost.com/kick-start/