Thu, 28 May 2015 10:00:22 -0700 bundle2: add an informative comment to the capability dict
Pierre-Yves David <pierre-yves.david@fb.com> [Thu, 28 May 2015 10:00:22 -0700] rev 25317
bundle2: add an informative comment to the capability dict It is fairly easy to get confused by capabilities "missing" from this dict. We make it clear the dict is not the whole story.
Thu, 28 May 2015 16:09:42 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Thu, 28 May 2015 16:09:42 -0500] rev 25316
merge with stable
Tue, 26 May 2015 23:02:19 -0700 bundle2: handle new line in 'outdebug' function
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 26 May 2015 23:02:19 -0700] rev 25315
bundle2: handle new line in 'outdebug' function Now that we have a prefix, it make sense to assume all output will be on a single line.
Tue, 26 May 2015 22:57:35 -0700 bundle2: prefix all bundling debug messages with 'bundle2-ouput:'
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 26 May 2015 22:57:35 -0700] rev 25314
bundle2: prefix all bundling debug messages with 'bundle2-ouput:' This makes the origin of the message more explicit.
Tue, 26 May 2015 22:49:03 -0700 bundle2: introduce a specific function for bundling debug message
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 26 May 2015 22:49:03 -0700] rev 25313
bundle2: introduce a specific function for bundling debug message The bundling process is very verbose, we would like to be able to hide such output behind a configuration flag and have it more explicitly referencing bundle2. The first step is to gather all these messages in a dedicated function. The same gathering will be later do for debug message issue by unbundling.
Wed, 27 May 2015 17:01:43 -0700 parsers: simplify the code computing the phases
Laurent Charignon <lcharignon@fb.com> [Wed, 27 May 2015 17:01:43 -0700] rev 25312
parsers: simplify the code computing the phases We recently simplified the code computing the heads of a repo. This patch uses the same simplification for phase computation. We use index_get_parents instead of replicating its code.
Wed, 27 May 2015 17:00:28 -0700 parsers: move index_get_parents's declaration higher
Laurent Charignon <lcharignon@fb.com> [Wed, 27 May 2015 17:00:28 -0700] rev 25311
parsers: move index_get_parents's declaration higher index_get_parents needs to be used in the phase computation code so we need to move its declaration higher to be able to call it. It cannot be moved any higher than that so we won't have any more patch doing the same thing.
Wed, 27 May 2015 15:49:24 -0700 record: add an operation arguments to customize recording ui
Laurent Charignon <lcharignon@fb.com> [Wed, 27 May 2015 15:49:24 -0700] rev 25310
record: add an operation arguments to customize recording ui This patch is part of a series of patches to change the recording ui to reflect the operation currently running (commit, shelve, revert ...). This patch adds a new argument to the recording function to reflect in the UI what operation we are running.
Sun, 26 Apr 2015 18:13:48 +0900 revset: reduce nesting of chained 'or' operations (issue4624)
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Apr 2015 18:13:48 +0900] rev 25309
revset: reduce nesting of chained 'or' operations (issue4624) This reduces the stack depth of chained 'or' operations: - from O(n) to O(1) at the parsing, alias expansion and optimization phases - from O(n) to O(log(n)) at the evaluation phase simplifyinfixops() must be applied immediately after the parsing phase. Otherwise, alias expansion would crash by "maximum recursion depth exceeded" error. Test cases use 'x:y|y:z' instead of 'x|y' because I'm planning to optimize 'x|y' in a different way. Benchmarks: 0) 605b1d32c1c0 1) this patch revset #0: 0 + 1 + 2 + ... + 200 0) wall 0.026347 comb 0.030000 user 0.030000 sys 0.000000 (best of 101) 1) wall 0.023858 comb 0.030000 user 0.030000 sys 0.000000 (best of 112) revset #1: 0 + 1 + 2 + ... + 1000 0) maximum recursion depth exceeded 1) wall 0.483341 comb 0.480000 user 0.480000 sys 0.000000 (best of 20) revset #2: sort(0 + 1 + 2 + ... + 200) 0) wall 0.013404 comb 0.010000 user 0.010000 sys 0.000000 (best of 196) 1) wall 0.006814 comb 0.010000 user 0.010000 sys 0.000000 (best of 375) revset #3: sort(0 + 1 + 2 + ... + 1000) 0) maximum recursion depth exceeded 1) wall 0.035240 comb 0.040000 user 0.040000 sys 0.000000 (best of 100)
Sun, 24 May 2015 14:10:52 +0900 revset: add helper to build balanced addsets from chained 'or' operations
Yuya Nishihara <yuya@tcha.org> [Sun, 24 May 2015 14:10:52 +0900] rev 25308
revset: add helper to build balanced addsets from chained 'or' operations This function will be used by revset.orset() and scmutil.revrange() to reduce the stack depth from O(n) to O(log(n)). We've bikeshed the interface of this function, but we couldn't come to an agreement. So we decided to attempt to make it move forward. marmoute: - new factory function isn't necessary for balanced addsets - addset.__init__ can just recurse, should handle "len(subsets) == 2+" yuja: - want to write all "len(subsets) == 0, 1, 2, 3+" cases in the same function - no recursion in __init__ for cosmetic reason: can't return, can't call __init__ directly I've changed it to a private function so that nobody would be tempted to utilize it.
Sun, 26 Apr 2015 18:27:32 +0900 revset: comment that we can't swap 'or' operands by weight
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Apr 2015 18:27:32 +0900] rev 25307
revset: comment that we can't swap 'or' operands by weight Though the original code did nothing, it tried to optimize the calculation order by weight. But we can't simply swap 'ta' and 'tb' because it would change the order of revisions. For future reference, this patch keeps the modified version of the original code as comment.
Sun, 26 Apr 2015 18:05:23 +0900 parser: add helper to reduce nesting of chained infix operations
Yuya Nishihara <yuya@tcha.org> [Sun, 26 Apr 2015 18:05:23 +0900] rev 25306
parser: add helper to reduce nesting of chained infix operations This will be used to avoid stack overflow caused by chained 'or' operations in revset.
(0) -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 +3000 +10000 tip