[RFC] Pushkey Concept

[Henrik Stuart]

Greg Ward wrote:
> On Mon, Sep 21, 2009 at 7:59 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote:
>>>  - puskey(string namespace, string key, string value, boolean force=False)
>>>  - listkeys(string namespace)
>> I hope you meant 'pushkey' instead of 'puskey' there? I'd prefer
>> pushkey to accept a dictionary like {'bookmarks': {'mybookmark':
>> '34abc3254'}}, so we can reduce the number of roundtrips if we want to
>> push many keys in one go.

> Incidentally, I have a great use case for this protocol extension that
> has nothing to do with bookmarks or tags: bugmap.  That is, I have
> written an extension for work that associates bug IDs with changeset
> IDs.  You use it like
> 
>   hg commit --bug 432 --bug 325 -m"fix two bugs"
> 
> which adds a line to .hg/bugmap.  Around the time of pushing that
> changeset, you also need to run
> 
>   hg pushbugs
> 
> which connects to a configured MySQL server and turns the line in
> .hg/bugmap into two rows of a bugmap table.  (It then writes a new
> empty .hg/bugmap.)  My extension wraps 'push' to make this automatic,
> but the manual command is there just in case.
> 
> It would be great if this information could be sent over the same
> channel as a regular 'hg push', and let server-side code worry about
> turning it into database rows.

There are several nice use-cases that Martin Geisler and I have
discussed several times before: automatically signing off on changesets
when you push them, GPG/X.509-signing changesets without having separate
changesets representing these things, etc.

Keeping this functionality hidden away so only core Mercurial has access
to it is, in my opinion, a mistake. Adding a guideline to extension
writers that if they are using the pushkey/listkey functionality they
have to provide backwards compatibility then that ought to be
sufficient. If it's a concern that they might violate this guideline,
then it should be possible to wrap up the call into each extension for
this functionality so push/pull/clone can easily say "extension foo
failed on the remote/local end. go hit the developer on the head." and
then promptly disable that extension.

Giving extensions more autonomy and flexibility does not mean that
Mercurial automatically becomes more brittle. Versioning data should be
left to the individual extension.

-- 
Kind regards,
  Henrik Stuart