[RFC] external revsets and templates
Yuya Nishihara
yuya at tcha.org
Sun Jul 17 09:42:57 EDT 2016
On Wed, 13 Jul 2016 13:37:08 -0500, Matt Mackall wrote:
> 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)"
I slightly prefer explicit function syntax because symbols and functions
live in different spaces.
[extrevset]
cvs(rev) = shell:/path/to/lookup-cvs-rev $rev
> 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.
[snip]
> 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.
Maybe the data source could be JSON output, SQLite file, etc., but I guess it
would complicate things. Also, I don't know if there is a widely-used query
language for JSON.
[exttemplate]
reviewers = http://example.com/
reviewers:filter = .reviews[]
reviewers:select = .node
reviewers:value = .assignee
{"reviews": [{"node": "abcdef...", {"assignee": ["foo", "bar", ...]}, ...
> 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.
mapping['cache'] can be used for a cache of displayer lifetime, but assuming the
data source will be shared across revset and templater, repo-level cache seems
better.
More information about the Mercurial-devel
mailing list