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

Matt Mackall mpm at selenic.com
Tue Oct 18 12:51:59 CDT 2011


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

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

Look: subrepos are FUNDAMENTALLY a hack. SVN and CVS were designed from
the ground up around nesting, Mercurial is precisely the opposite. I
don't even know how I'd start to write a DVCS that did this cleanly. And
I'm pretty sure it's impossible to make Mercurial + subrepos anywhere
near as nice as just plain Mercurial. No amount of dogfooding is going
to close the huge conceptual divide to Mercurial's monolithic model:
there will ALWAYS be visible evidence of the mismatch in the form of
suckage.

I don't want to deal with that suckage every day. And I don't want more
users to look at us and say "they do it, it must be best practice for my
little project" and then have to deal with that suckage every day too.
Instead our example should be "huh, they're not using them, perhaps
there's a reason not to".

Subrepos are just not ever going to be best way for most people to use
Mercurial. So I'm just not going to get excited about this idea. Ever.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list