httpclient as subrepo, Was: [PATCH] httpclient: update to 07d8c356f4d1 of py-nonblocking-http

Mads Kiilerich mads at kiilerich.com
Thu Oct 13 07:42:38 CDT 2011


On 10/13/2011 12:38 PM, Martin Geisler wrote:
> Augie Fackler<durin42 at gmail.com>  writes:
>
>> # HG changeset patch
>> # User Augie Fackler<durin42 at gmail.com>
>> # Date 1318287460 18000
>> # Node ID 690ae3afd04d88a46a18e85ba189bf11c58bf1bf
>> # Parent  231aac5280baae0614d7f278bb306b95c4a1488b
>> httpclient: update to 07d8c356f4d1 of py-nonblocking-http
>
> Wouldn't it be nice if we could just go into the mercurial/httpclient
> subrepo and run 'hg incoming to see if there's anything new upstream
> that we should care about?

No. I'm quite confident that "upstream" knows what we should care about.

In order to be able to just run 'hg incoming' the subrepository would 
have to be defined with an absolute url. That is always a bad idea. 
Something extra would have to be done to get this "benefit", so the 
rhetorical question you ask has a false premise.

> I think we should acknowledge that core Mercurial now has an optional
> runtime dependency on another Python library. It's a library that we're
> shipping with Mercurial and one that we (as far as I know) aim to make
> mandatory at some point when we trust it.

Right now it is a mandatory dependency because it is optional on runtime.

Including it as a subrepo would be a mandatory dependency. That could be 
OK, but it has a much higher cost than bundling it and it has no benefits.

If it really was optional it would be a better solution to pull it in 
from the build system when needed, without using subrepos.

> Should we not incorporate it using the tools we have? We could make a
> hg-build "super" repo that has mercurial and py-nonblocking-http as
> subrepos, the important thing is that we (Matt and crew and other
> Mercurial developers) begin using subrepos on a daily basis.

IMHO subrepos is the kind of dog food that you _can_ eat, there might 
not be any better options, and in some situations it might be the best 
and only and right choice to eat it. It is however not something that 
gives a lot of pleasure or is recommended if there is any other option.

Subrepos is included in core Mercurial, but would anybody call it a 
"core feature"? I don't think it is something we should use just because 
it is in core.

A bit more controversial: I'm getting more and more convinced that:

* subrepos might be a usable solution to some use cases it was designed 
to solve, but the implementation is still incomplete and not (yet?) a 
good solution for any usecases

* subrepos wasn't designed to solve the use cases I would expect was 
essential for subrepos, and I don't know or understand the use cases it 
was designed to solve

* with subrepos as a core feature with the strict compatibility 
requirements I don't see any way that subrepos could evolve to being a 
good general solution

* I think the best recommendation for enterprises with a need for 
"subrepos" would be to forget about core subrepos and create an 
extension by copying and rewriting the existing core subrepo functionality

/Mads


More information about the Mercurial-devel mailing list