[patch 4/4] This adds support for an [extensions] section to hgrc. This has the form of:

[Robin Farine]

On Saturday 13 August 2005 14.00, Chris Mason wrote:
> Matt Mackall wrote:
> > On Fri, Aug 12, 2005 at 01:55:55PM -0400, Chris Mason wrote:
> >>On Friday 12 August 2005 13:18, Bryan O'Sullivan wrote:
> >>>Here's the approach I'd prefer to see.  This changes the way
> >>>repositories are created so that you can customise it.  Just
> >>> modify the contents of hg.protocols, and you're done.  In
> >>> your case, you'd want to subclass localrepository, then set
> >>> protocols['file'] to return one of your new objects.
> >>
> >>I have mixed feelings on this one...Matt, how would you rather
> >> see it work?
> >
> > I kind of like it, though I'd rather see lambdas and some other
> > minor details. Any specific objections?
>
> Mostly I don't like the requirement of subclassing off
> localrepository. But I guess this is more of a grumpy C
> programmer objection than anything else.

Perhaps I fail to get the whole thing, in which case I apologize for 
the noise, but I agree with you. Not with the grumpy C programmer 
reason though :-).

As I understand it, in general an extension can add commands to 
Mercurial and may need to associate some repository specific state 
with a local repo. It can also add support for a new protocol to 
access a remote repository but this is a very specific case. 
Bryan's solution of having a repository factory handles this case 
perfectly.

But if an extension module like Chris' mq has to subclass 
localrepository to add extension-specific state to repo objects, 
what happens when two or more such extensions have to coexist? This 
indicates that extensions must not subclass localrepository.

Robin