[PATCH V2] revset: define successors revset

[Jun Wu]

Excerpts from Matt Harbison's message of 2017-07-12 00:25:47 -0400:
> This will be more of an issue with precursors(), which I assume will be  
> defined the same way for consistency.  I tend to use the following to make  
> sure that conflicts were resolved properly after rebasing:
> 
>     $ hg extdiff --patch --hidden -r "precursors($rev)" -r "$rev"
> 
> It can be especially handy in a loop when a series is rebased and several  
> commits need to be reviewed.  Depth=1 probably solves that.  I only  
> mention it to provide an actual use case.  Hopefully this remains working  
> one way or the other in 4.3.

Yes, I was aware of the use-case. We also have internal users wanting to
compare with a previous version.

Note: we have decided to use "predecessor" instead of "precursors" [1].
A "predecessors" revset is planned. However, I think the current obsstore
API need some change to support depth better. Since I'm also planning on new
(hash-preserving) obsstore format and API, I don't want to spend too much
time on things only working for the format obsstore.

The successors revset is mainly to be used together with my rebase work,
where you can use:

  hg rebase -s 'unstable()-obsolete()' -d 'max(successors(max(roots(ALLSRC) & ::SRC)^)-obsolete()-divergent())'

to basically achieve what "evolve --all" can do today, even with more
flexibility like you can move the destination approximately to a head:

  hg rebase -s 'unstable()-obsolete()' -d 'max((successors(max(roots(ALLSRC) & ::SRC)^)-obsolete()-divergent())::)'

(I'd wish that feature to be available in 4.3, but that's just a wish)

Predecessor revset is not needed for that so it's less prioritized.

[1]: https://www.mercurial-scm.org/wiki/CEDVocabulary