[PATCH 2 of 4] schemas: add wireproto implementations of schema passing

Durham Goode durham at fb.com
Fri Aug 9 16:20:31 CDT 2013

On 8/9/13 4:40 AM, "Martin Geisler" <martin at geisler.net> wrote:

>Augie Fackler <raf at durin42.com> writes:
>> On Tue, Aug 06, 2013 at 05:28:27PM -0700, Durham Goode wrote:
>>> # HG changeset patch
>>> # User Durham Goode <durham at fb.com>
>>> # Date 1375827497 25200
>>> #      Tue Aug 06 15:18:17 2013 -0700
>>> # Node ID ef29e2e8de0198d5041f60e9cbfc7b5a29fea93d
>>> # Parent  f6fca02b697a67bec6e6ca2c9a48d7c7d7f1d077
>>> schemas: add wireproto implementations of schema passing
>> Why this instead of some pushkey love? This feels like a very good fit
>> for pushkey and a 3rd-party extension as a way to test the idea.
>Pushkey is the approach taken by the projrc extension and it shows that
>it's possible to write this as an extension.
>Like Angel, I would like to see some core mechanism for distributing
>config settings. It need not be the way projrc does it -- since it was
>written as an extension, it (ab)uses the pushkey concept and it also
>hooks into some low-level stuff to inject the settings.
>Having better support for that in core would simplify the projrc
>extension and perhaps make it possible to write a small extension for
>distributing what you call "schemas" in case the full (and somewhat
>scary) projrc functionality isn't needed.

Just brainstorming, but what if we had a projrc-like extension where the
settings were kept in a hgrc style file (.hg/remoterc or whatever) but not
included in the normal config lookup.  So any time mercurial or an
extension wanted to look something up from it they would have to
explicitly run something like ui.configRemote(Š).  So it's a bit more
generic than schemas, but hooks/aliases/etc couldn't be slipped in (unless
you enabled a malicious extension).

That's basically what my schemas stuff is (a key/value map) but you'd look
it up via ui.configRemote(k) instead of repo.schemas[k]

More information about the Mercurial-devel mailing list