Tue, 13 Sep 2016 16:25:21 -0700 manifest: add manifestctx.readdelta()
Durham Goode <durham@fb.com> [Tue, 13 Sep 2016 16:25:21 -0700] rev 29938
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.
Wed, 14 Sep 2016 17:12:39 +0200 merge with stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Wed, 14 Sep 2016 17:12:39 +0200] rev 29937
merge with stable
Tue, 13 Sep 2016 13:49:42 -0700 rebase: make debug logging more consistent
Martin von Zweigbergk <martinvonz@google.com> [Tue, 13 Sep 2016 13:49:42 -0700] rev 29936
rebase: make debug logging more consistent We emit some lines that mix revision numbers with nodeids, which makes little sense to me.
Sun, 26 Jun 2016 18:41:28 +0900 revset: fix order of nested '_(|int|hex)list' expression (BC)
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Jun 2016 18:41:28 +0900] rev 29935
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.
Sun, 26 Jun 2016 18:17:12 +0900 revset: fix order of nested 'or' expression (BC)
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Jun 2016 18:17:12 +0900] rev 29934
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)
Sun, 07 Aug 2016 17:58:50 +0900 revset: add 'takeorder' attribute to mark functions that need ordering flag
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:58:50 +0900] rev 29933
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.
Sun, 07 Aug 2016 17:46:12 +0900 revset: pass around ordering flags to operations
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:46:12 +0900] rev 29932
revset: pass around ordering flags to operations Some operations and functions will need them to fix ordering bugs.
Sun, 07 Aug 2016 17:48:52 +0900 revset: add stub to handle parentpost operation
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:48:52 +0900] rev 29931
revset: add stub to handle parentpost operation All operations will take 'order' flag, but p1() function won't.
Tue, 16 Feb 2016 22:02:16 +0900 revset: infer ordering flag to teach if operation should define/follow order
Yuya Nishihara <yuya@tcha.org> [Tue, 16 Feb 2016 22:02:16 +0900] rev 29930
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'.
Sun, 07 Aug 2016 17:04:05 +0900 revset: wrap arguments of 'or' by 'list' node
Yuya Nishihara <yuya@tcha.org> [Sun, 07 Aug 2016 17:04:05 +0900] rev 29929
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:].
Tue, 13 Sep 2016 20:30:19 +0200 journal: properly check for held lock (issue5349)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 13 Sep 2016 20:30:19 +0200] rev 29928
journal: properly check for held lock (issue5349) The 'jlock' code meant to check for a held lock, but it actually just checking for a lock object. With CPython, this worked because the 'jlock' object is not referenced outside the '_write' function so reference counting would garbage collect it and the '_lockref' would return None. With pypy, the garbage collection would happen at an undefined time and the '_lockref' can still point to a 'jlock' object outside of '_write'. The right thing to do here is not only to check for a lock object but also to check if the lock is held. We update the code to do so and reuse a utility method that exist on 'localrepo' to help readability. This fix journal related tests with pypy.
Tue, 13 Sep 2016 17:46:29 +0200 ssl: handle a difference in SSLError with pypy (issue5348)
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Tue, 13 Sep 2016 17:46:29 +0200] rev 29927
ssl: handle a difference in SSLError with pypy (issue5348) The SSLError exception is a bit different with pypy (message is the first argument, not the second) This led the certificate error handling to crash when trying to extract the ssl error message. We now handle this different and 'test-https.t' is green again.
Mon, 12 Sep 2016 10:55:43 -0700 manifest: change manifestctx to not inherit from manifestdict
Durham Goode <durham@fb.com> [Mon, 12 Sep 2016 10:55:43 -0700] rev 29926
manifest: change manifestctx to not inherit from manifestdict If manifestctx inherits from manifestdict, it requires some weird logic to lazily load the dict if a piece of information is asked for. This ended up being complicated and unintuitive to use. Let's move the dict creation to .read(). This will make even more sense once we start adding readdelta() and other similar methods to manifestctx.
Mon, 12 Sep 2016 14:29:09 -0700 manifest: make one use of _mancache avoid manifestctxs
Durham Goode <durham@fb.com> [Mon, 12 Sep 2016 14:29:09 -0700] rev 29925
manifest: make one use of _mancache avoid manifestctxs In a future patch we will change manifestctx and treemanifestctx to no longer derive from manifestdict and treemanifest, respectively. This means that consumers of the _mancache will now need to be aware of the different between the two, until we get rid of the manifest entirely and the _mancache becomes only filled with ctxs. This fixes one case of it that can be fixed by using the other cache. Future patches will address the others uses using the upcoming manifestctx.read() function.
Sun, 21 Aug 2016 13:16:21 +0900 debugrevspec: add option to verify optimized result
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Aug 2016 13:16:21 +0900] rev 29924
debugrevspec: add option to verify optimized result This provides a convenient way to diff "hg debugrevspec" outputs generated with/without --no-optimized option.
Sun, 21 Aug 2016 12:40:02 +0900 debugrevspec: add option to skip optimize() and evaluate unoptimized tree
Yuya Nishihara <yuya@tcha.org> [Sun, 21 Aug 2016 12:40:02 +0900] rev 29923
debugrevspec: add option to skip optimize() and evaluate unoptimized tree This will help debugging optimizer bugs. Maybe '--no-optimized' can be changed to '--optimized' (default: True) when flags series landed.
(0) -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 tip