[RFC] revision sets

[Peter Arrenbrecht]

On Tue, Apr 20, 2010 at 12:32 AM, Matt Mackall <mpm at selenic.com> wrote:
> Right now we have a notion of revision ranges, ie:
>
>  hg log -r 0:1.0
>
> Internally, we iterate over this with something like:
>
>  for rev in commandutil.revrange(opts['rev']):
>
> I've been talking about expanding this into a more powerful system that
> would allow specifying dates, keywords, branches, etc. My current
> thought is to make it look like this:
>
>  hg log -r "branch(foo) and keyword(bar) and date(mar 1 - apr 1)"
>
> Which would be identical to:
>
>  hg log -b foo -k bar -d "mar 1 - apr 1"
>
> but would magically work anywhere -r ranges were accepted (export, push,
> etc.).
>
> Further, we'd be able to add lots of interesting primitives:
>
>  hg log -r "descendant(parent2(1.0)) and ancestor(2.0) and
> author(george) and sorted(date) and reversed()"
>
> Read that as: every cset that is descended from the second parent of
> revision 1.0 and is also an ancestor of 2.0 and was written by george,
> sorted by date in reverse order.
>
> revrange would be replaced by a new revset function that would parse the
> query/queries and build an iterator. Some of the operations, like
> keyword() and author(), would obviously be fairly expensive and many
> would fail to work (at least for now) on remote repos.
>
> I've pitched an idea like this before, usually with a weird
> operator-intensive syntax. This time, I think the right thing is an
> easily-read but more verbose query language.
>
> Steps to get from here to there:
>
> - change all callers of revrange to revset
> - design a BNF for the revset query language
> - build a query parser/"compiler"
> - add filters for the query functions
> - simplify some of the existing options (like -d and -k) by turning them
> into queries internally
>
> Thoughts?

Like the verbosity for this as a default. Parametrized templates might
come in handy for people needing the same kind of filter time and
again. So:

  [filters]
  partof(r) = r or ancestor(r)
  incoming(new,old) = partof(new) and not partof(old)

and then

  hg log -r "incoming(1.1, 1.0)"

For things like glog it might be nice to have an API that feeds the
base walk into the filter and gets true/false responses. This is so
glog can still try to show something reasonable when forks or joins
are rejected by the filter.

-parren