revset: fix order of nested 'or' expression (BC)
This fixes the order of 'x & (y + z)' where 'y' and 'z' are not trivial.
The follow-order 'or' operation is slower than the ordered operation if
an input set is large:
#0 #1 #2 #3
0) 0.002968 0.002980 0.002982 0.073042
1) 0.004513 0.004485 0.012029 0.075261
#0: 0:4000 & (0:1099 + 1000:2099 + 2000:3099)
#1: 4000:0 & (0:1099 + 1000:2099 + 2000:3099)
#2: 10000:0 & (0:1099 + 1000:2099 + 2000:3099)
#3: file("path:hg") & (0:1099 + 1000:2099 + 2000:3099)
I've tried another implementation, but which appeared to be slower than
this version.
ss = [getset(repo, fullreposet(repo), x) for x in xs]
return subset.filter(lambda r: any(r in s for s in ss), cache=False)
This test file aims at test topological iteration and the various configuration it can has.
$ cat >> $HGRCPATH << EOF
> [ui]
> logtemplate={rev}\n
> EOF
On this simple example, all topological branch are displayed in turn until we
can finally display 0. this implies skipping from 8 to 3 and coming back to 7
later.
$ hg init test01
$ cd test01
$ hg unbundle $TESTDIR/bundles/remote.hg
adding changesets
adding manifests
adding file changes
added 9 changesets with 7 changes to 4 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg log -G
o 8
|
| o 7
| |
| o 6
| |
| o 5
| |
| o 4
| |
o | 3
| |
o | 2
| |
o | 1
|/
o 0
(display all nodes)
$ hg log -G -r 'sort(all(), topo)'
o 8
|
o 3
|
o 2
|
o 1
|
| o 7
| |
| o 6
| |
| o 5
| |
| o 4
|/
o 0
(revset skipping nodes)
$ hg log -G --rev 'sort(not (2+6), topo)'
o 8
|
o 3
:
o 1
|
| o 7
| :
| o 5
| |
| o 4
|/
o 0
(begin) from the other branch
$ hg log -G -r 'sort(all(), topo, topo.firstbranch=5)'
o 7
|
o 6
|
o 5
|
o 4
|
| o 8
| |
| o 3
| |
| o 2
| |
| o 1
|/
o 0