httpclient as subrepo, Was: [PATCH] httpclient: update to 07d8c356f4d1 of py-nonblocking-http
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
More information about the Mercurial-devel