Sun, 24 May 2015 18:30:27 +0900 revrange: build spanset from x:y range
Yuya Nishihara <yuya@tcha.org> [Sun, 24 May 2015 18:30:27 +0900] rev 25386
revrange: build spanset from x:y range This slightly improves the performance in the optimal case: % hg log -R mozilla-central -r0:tip -l1 --time (before) time: real 0.050 secs (user 0.040+0.000 sys 0.010+0.000) (after) time: real 0.020 secs (user 0.000+0.000 sys 0.010+0.000)
Sun, 24 May 2015 18:11:33 +0900 revrange: build balanced tree of addsets from revisions (issue4565)
Yuya Nishihara <yuya@tcha.org> [Sun, 24 May 2015 18:11:33 +0900] rev 25385
revrange: build balanced tree of addsets from revisions (issue4565) This reduces the stack depth from O(n) to O(log(n)). Therefore, repeated -rREV options will never exceed the Python stack limit. Currently it depends on private revset._combinesets() function. But at some point, we'll be able to drop the old-style parser, and revrange() can be completely rewritten without using _combinesets(): trees = [parse(s) for s in revs] optimize(('or',) + trees) # combine trees and optimize at once ... Blockers that prevent eliminating old-style parser: - nullary ":" operator - revrange(repo, [intrev, ...]), can be mapped to 'rev(%d)' ? - revrange(repo, [binnode, ...]), should be banned ?
Sun, 24 May 2015 17:59:55 +0900 revrange: clean up meaningless reconstruction of sets
Yuya Nishihara <yuya@tcha.org> [Sun, 24 May 2015 17:59:55 +0900] rev 25384
revrange: clean up meaningless reconstruction of sets They just exist for deduplication that was removed by the previous patch.
Sun, 24 May 2015 17:53:22 +0900 revrange: drop unnecessary deduplication of revisions
Yuya Nishihara <yuya@tcha.org> [Sun, 24 May 2015 17:53:22 +0900] rev 25383
revrange: drop unnecessary deduplication of revisions Because "l" is a smartset, duplicated entries are omitted by addsets.
Fri, 29 May 2015 22:23:58 +0200 summary: move the parents phase marker to commit line (issue4688)
Gilles Moris <gilles.moris@free.fr> [Fri, 29 May 2015 22:23:58 +0200] rev 25382
summary: move the parents phase marker to commit line (issue4688) The phase of the pending commit depends on the parent of the working directory and on the phases.newcommit configuration. First, this information rather depend on the commit line which describe the pending commit. Then, we only want to be advertised when the pending phase is going to be higher than the default new commit phase. So the format will change from $ hg summary parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) update: (current) phases: 1 secret (secret) to parent: 2:ab91dfabc5ad foo parent: 3:24f1031ad244 tip bar branch: default commit: 1 modified, 1 unknown, 1 unresolved (merge) (secret) update: (current) phases: 1 secret
Mon, 25 May 2015 16:48:55 -0700 tags: support setting hgtags fnodes cache entries
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 25 May 2015 16:48:55 -0700] rev 25381
tags: support setting hgtags fnodes cache entries An upcoming patch will teach bundle2 to transfer .hgtags fnodes values. To support this, we need to support inserting values into the cache. Add functionality to do that.
Mon, 25 May 2015 16:24:23 -0700 tags: support reading tags cache without populating
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 25 May 2015 16:24:23 -0700] rev 25380
tags: support reading tags cache without populating An upcoming patch will teach the bundle2 protocol to transfer .hgtags fnodes to the client. We don't want this to incur any extra work at serve time. Create an optional cache query mode that doesn't populate the cache as a side-effect.
Sun, 31 May 2015 17:41:35 -0700 check-commit: make foo_bar naming regexp less greedy
Gregory Szorc <gregory.szorc@gmail.com> [Sun, 31 May 2015 17:41:35 -0700] rev 25379
check-commit: make foo_bar naming regexp less greedy \s is equivalent to the character class [ \t\n\r\f\v]. Using \s+ in a regular expression against input with multiple lines may match across multiple lines. For the regexp in question, "\+\s+" would match "+\n " and similar sequences, leading to false positives for functions that were included in diff context, after a modified hunk.
Wed, 27 May 2015 12:05:08 -0700 test: use bundle2 in test-http
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 12:05:08 -0700] rev 25378
test: use bundle2 in test-http Now that we have a bundle1 version of this test, we can move the original to bundle2. This lets us handle the ouput change from using the bundle2 protocol earlier.
Wed, 27 May 2015 12:03:31 -0700 test: copy test-http.t to test-http-bundle1.t
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 27 May 2015 12:03:31 -0700] rev 25377
test: copy test-http.t to test-http-bundle1.t We want to keep both code paths tested. The test is a bit too extensive to simply introduce dual testing in it so we make a copy for each protocol version.
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip