revset: add startdepth limit to ancestors() as internal option
This is necessary to implement the set{gen} (set subscript) operator. For
example, set{-n} will be translated to ancestors(set, depth=n, startdepth=n).
https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm
The UI is undecided and I doubt if the startdepth option would be actually
useful, so the option is hidden for now. 'depth' could be extended to take
min:max range, in which case, integer depth should select a single generation.
ancestors(set, depth=:y) # scan up to y-th generation
ancestors(set, depth=x:) # skip until (x-1)-th generation
ancestors(set, depth=x) # select only x-th generation
Any ideas are welcomed.
# reverse(ancestors(tip)) using hg repo
3) 0.075951
4) 0.076175
revset: add depth limit to ancestors()
This is proposed by the
issue5374, and will be a building block of set{gen}
(set subscript) operator.
https://www.mercurial-scm.org/wiki/RevsetOperatorPlan#ideas_from_mpm
# reverse(ancestors(tip)) using hg repo
2) 0.075408
3) 0.075951
dagop: compute depth in revancestors() generator
Surprisingly, this makes revset benchmark slightly faster. I don't know why,
but it appears that wrapping -inputrev by tuple is the key. So I decided to
just enable depth computation by default.
# reverse(ancestors(tip)) using hg repo
1) 0.081051
2) 0.075408
dagop: just compare with the last value to deduplicate input of revancestors()
Since we're using a max heap, the current rev should be a duplicate only
if it equals to the previous one. We don't have to maintain the whole seen
set.
# reverse(ancestors(tip)) using hg repo
0) 0.086420
1) 0.081051
dagop: bulk rename variables in revancestors() generator
- h -> pendingheap: "h" seems too short for variable of long lifetime
- current -> currev: future patches will add current "depth" variable
- parent -> prev or pctx: short lifetime, follows common naming rules
dagop: comment why revancestors() doesn't heapify input revs at once
I wondered why we're doing this complicated stuff without noticing the input
revs may be iterated lazily in descending order.
c1f666e27345 showed why.
dagop: unnest inner generator of revancestors()
This just moves iterate() to module-level function.