2.3 upgrade notes: remote repository API

Matt Mackall mpm at selenic.com
Mon Sep 17 17:33:57 CDT 2012


On Tue, 2012-09-18 at 00:08 +0200, Arne Babenhauserheide wrote:
> Hi Matt,
> 
> Am Montag, 17. September 2012, 13:36:24 schrieb Matt Mackall:
> > http://mercurial.selenic.com/wiki/MercurialApi#Why_you_shouldn.27t_use_Mercu
> > rial.27s_internal_API
> > 
> > ..more or less sums up why this is out of scope for UpgradeNotes.
> > 
> > I think the next step I'm going to take is to start actively denying the
> > import of Mercurial modules unless you set:
> > 
> > iacknowledgethatmercurialisnotalibraryandishouldntdependonitsinternals =
> > True
> 
> So, what can I do if I wrote an extension which provides some functionality 
> for which I need to be able to hook into internal functions?
> 
> hggit, hgsubversion, staticsite and infocalypse are examples.
> 
> How can I make it less likely that they get broken by a hg update?

Depend on fewer (preferably no) internals.

Yes, I know that hggit and the like are basically impossible to
implement without mucking about in Mercurial's internals. Their
collateral breakage when Mercurial internals evolve _is the price you
have to pay for that level of access_.

None of this is news from this decade, folks. 

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list