[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