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

[Franklin M. Siler]

On Thu, Oct 20, 2011 at 11:51, Matt Mackall <mpm at selenic.com> wrote:
> 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:
[snip]
>> >> 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.
>>
It may be true that in MANY cases this is true, but why should the
tool dictate to users what they can and cannot use the tool for?  In
many cases, the most interesting uses of tools come about when they
are built around doing one task very well and the users come up with
interesting uses- for example, the humble nail, toothpick, or claw
hammer have a number of interesting uses far beyond the intended ones.
 There doesn't seem to be much question that subrepos are a powerful
feature which requires some knowledge and experience to use well- but
this is true with almost any large, powerful tool.  I predict that
users will find productive and interesting use cases beyond those
envisioned- and I think the use cases presented so far are overly
narrow.

> - 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.

Abstractions leak. Tools have limitations. As long as the pitfalls are
documented (and in my brief experience with hg, I have learned that
they generally are), what's the problem?

I'd also like to note happily that in many cases, the recommendations
seem fairly conservative.  Despite the warnings, I am using hg to
version >60GB of music files now- almost 9000 mp3 and AAC files, and
it works very well except that push seems to take a long time and a
relatively large amount of bandwidth relative to the delta size, but I
haven't yet investigated the reasons for this.

I am reading through source and working on my "optional subrepo"
feature, but I would also like to fix "add" as Matt suggested.  Is
anyone else working on this or related features?  Thanks.

Frank