Durham Goode <durham@fb.com> [Tue, 13 Sep 2016 16:25:21 -0700] rev 29942
manifest: add manifestctx.readdelta()
This adds an implementation of readdelta to the new manifestctx class and adds a
couple consumers of it. This currently appears to have some duplicate code, but
future patches cause this function to diverge when things like "shallow" are
introduced.
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 14 Sep 2016 17:12:39 +0200] rev 29941
merge with stable
Martin von Zweigbergk <martinvonz@google.com> [Tue, 13 Sep 2016 13:49:42 -0700] rev 29940
rebase: make debug logging more consistent
We emit some lines that mix revision numbers with nodeids, which makes
little sense to me.
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Jun 2016 18:41:28 +0900] rev 29939
revset: fix order of nested '_(|int|hex)list' expression (BC)
This fixes the order of 'x & (y + z)' where 'y' and 'z' are trivial, and the
other uses of _list()-family functions. The original functions are renamed to
'_ordered(|int|hex)list' to say clearly that they do not follow the subset
ordering.
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Jun 2016 18:17:12 +0900] rev 29938
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)
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:58:50 +0900] rev 29937
revset: add 'takeorder' attribute to mark functions that need ordering flag
Since most functions shouldn't need 'order' flag, it is passed only when
explicitly required. This avoids large API breakage.
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:46:12 +0900] rev 29936
revset: pass around ordering flags to operations
Some operations and functions will need them to fix ordering bugs.
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:48:52 +0900] rev 29935
revset: add stub to handle parentpost operation
All operations will take 'order' flag, but p1() function won't.
Yuya Nishihara <yuya@tcha.org> [Tue, 16 Feb 2016 22:02:16 +0900] rev 29934
revset: infer ordering flag to teach if operation should define/follow order
New flag 'order' is the hint to determine if a function or operation can
enforce its ordering requirement or take the ordering already defined. It
will be used to fix a couple of ordering bugs, such as:
a) 'x & (y | z)' disregards the order of 'x' (issue5100)
b) 'x & y:z' is listed from 'y' to 'z'
c) 'x & y' can be rewritten as 'y & x' if weight(x) > weight(y)
(a) and (b) are bugs of the revset core. Before this, there was no way to
tell if 'orset()' and 'rangeset()' can enforce its ordering. These bugs
could be addressed by overriding __and__() of the initial set to take the
ordering of the other set:
class fullreposet:
def __and__(self, other):
# allow other to enforce its ordering
return other
but it would expose (c), which is a hidden bug of optimize(). So, in either
ways, optimize() have to know the current ordering requirement. Otherwise,
it couldn't rewrite expressions by weights with no output change, nor tell
how a revset function or operation should order the entries.
'order' is tri-state. It starts with 'define', and shifts to 'follow' by
'x & y'. It changes back to 'define' on function call 'f(x)' or function-like
operation 'x (f) y' because 'f' may have its own ordering requirement for 'x'
and 'y'. The state 'any' will allow us to avoid extra cost that would be
necessary to constrain ordering where it isn't important, 'not x'.
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:04:05 +0900] rev 29933
revset: wrap arguments of 'or' by 'list' node
This makes the number of 'or' arguments deterministic so we can attach
additional ordering flag to all operator nodes. See the next patch.
We rewrite the tree immediately after chained 'or' operations are flattened
by simplifyinfixops(), so we don't need to care if arguments are stored in
x[1] or x[1:].