[RFC] external revsets and templates

[Matt Mackall]

These are features we've been playing with a bit in the new review flow:

https://www.mercurial-scm.org/wiki/AcceptProcess#Setting_up_the_revset_helper

These have been extremely useful and I'd like to make them core feature, so I'd
like to further iron out the syntax and feature set before moving forward.

Currently, external revsets works like this:

 [extrevset]
 foo = shell:some-shell-command

Then some-shell-command is expected to return a series of Mercurial identifiers
(hash, rev, tag..), one per line. When "foo" is used in a revset, Mercurial
calls the shell command, looks up each result, and returns a corresponding
revset.

I think we should also be able to support arguments:

 [extrevset]
 cvs = shell:/path/to/lookup-cvs-rev $1

Then we can do:

 $ hg log -r "cvs(123)"

Also, we should allow data sources that are arbitrary URLs:

 [extrevset]
 tested = url:http://build.corp.example.com/hg-tested.dat
 good = url:http://build.corp.example.com/hg-passed.dat
 deployed = url:http://prod.example.com/hg-deployed.cgi
 fulltext = url:http://hg
-fulltext-db.example.com/query?string=$1

..which will allow very easy integration with complex production automation. The
url: piece might be redundant here? We might also allow calling Python, similar
to how we allow it in hooks.

My current implementation has no caching, which is usually fine. My plan is to
cache the non-argument version for the repo object lifetime and leave the
argument version uncached, but the chg use case might need a better plan.


External templates are very similar and allow adding data to the display side
(including in hgweb!). Instead of simply getting a list of revisions, it gets a
list of revision[space]description pairs. For instance, I can currently get a
list of reviewers on draft changesets thusly:

 [exttemplate]
 reviewers = shell:ssh mercurial-cm accept/reviewed

..and simply add {reviewers} to my log template. Again, this can be used for
many things, like displaying number of test failures, deployment status,
mappings to other SCMs or review tools.

Caching here is more important as templates get evaluated once per changeset. My
current hack keeps a global cache, but caching per repo is probably saner.

Because the data format for external templates is a superset of the one used by
external revsets, the same source can probably be shared in the cases where it
makes sense.

Thoughts?

-- 
Mathematics is the supreme nostalgia of our time.