[PATCH] httpclient: update to 07d8c356f4d1 of py-nonblocking-http
angel.ezquerra at gmail.com
Thu Oct 20 08:46:41 CDT 2011
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
>>> 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.
I would say that there is a compelling argument to be made that you
should be able to setup subrepos on the .hgsub file as follows:
And have it be equivalent to:
subrepo1 = subrepo1
subrepo2 = subrepo2
subrepoN = subrepoN
That way people would be far less likely to configure (and thus use)
More information about the Mercurial-devel