Wed, 19 Mar 2014 02:36:21 -0700 bundle2: add ability to write to a file to the test
Pierre-Yves David <pierre-yves.david@fb.com> [Wed, 19 Mar 2014 02:36:21 -0700] rev 20841
bundle2: add ability to write to a file to the test Next changesets are about improving debug output during bundling. We won't be able to simply bundle to stdin in this case. The bundle2 stream would be interleaved with debug output.
Fri, 21 Mar 2014 16:09:17 -0700 subrepo: factor out Git version check to add doctests
Siddharth Agarwal <sid0@fb.com> [Fri, 21 Mar 2014 16:09:17 -0700] rev 20840
subrepo: factor out Git version check to add doctests Followup to 6a2acb0d9352::e5641536e4d5.
Sat, 15 Feb 2014 19:51:20 +0900 contrib: add "hgperf" command to measure performance of commands easily
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 15 Feb 2014 19:51:20 +0900] rev 20839
contrib: add "hgperf" command to measure performance of commands easily Newly added "hgperf" command repeats "dispatch.runcommand()" for specified Mercurial command and measure performance of it in the same manner of "contrib/perf.py" extension. Users (mainly developers) can examine performance of the target command easily, without adding new entry for it to "contrib/perf.py" extension.
Sat, 15 Feb 2014 19:54:14 +0900 grep: exit loop immediately, if matching is found in the file for "hg grep -l"
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 15 Feb 2014 19:54:14 +0900] rev 20838
grep: exit loop immediately, if matching is found in the file for "hg grep -l" Before this patch, internal function "display()" of "hg grep" is not efficient for "-l"/"--files-with-matches", because loop is continued, even after the first matching is found in the specified file. This patch exits loop immediately, if matching is found for "--files-with-matches". In this case, "before is None" is equal to "opts.get('files_with_matches')".
Sat, 15 Feb 2014 19:54:05 +0900 grep: use "found" instead of "filerevmatches" examination for efficiency
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 15 Feb 2014 19:54:05 +0900] rev 20837
grep: use "found" instead of "filerevmatches" examination for efficiency Before this patch, internal function "display()" of "hg grep" stores whether matching is already found or not into the dictionary "filerevmatches" by "(fn, rev)" tuple as the key. But this is redundant, because: - "filerevmatches" is local variable of "display()", so each "display()" invocations don't affect others - both "fn" and "rev" (gotten from "ctx" argument) are never changed in each "display()" invocations Then, "filerevmatches" should have only one entry at most, and "(fn, rev) in filerevmatches" should be equal to "found". This patch uses "found" instead of "filerevmatches" examination for efficiency.
Sat, 15 Feb 2014 19:52:36 +0900 grep: reuse the first "util.binary()" result for efficiency
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 15 Feb 2014 19:52:36 +0900] rev 20836
grep: reuse the first "util.binary()" result for efficiency Before this patch, to check whether the file in the specified revision is binary or not, "util.binary()" is invoked via internal function "binary()" of "hg grep" once per a line of "hg grep" output, even though binary-ness is not changed in the same file. This patch reuses the first "util.binary()" invocation result by annotating internal function "binary()" with "@util.cachefunc". Performance improvement measured by "hgperf grep -r 88d8e568add1 vfs mercurial/scmutil.py": before this patch: ! wall 0.024000 comb 0.015600 user 0.015600 sys 0.000000 (best of 118) after this patch: ! wall 0.023000 comb 0.015600 user 0.015600 sys 0.000000 (best of 123) Status of recent(88d8e568add1) "mercurial/scmutil.py": # of lines: 919 (may affect cost of search) # of bytes: 29633 (may affect cost of "util.binary()") # of matches: 22 (may affect frequency of "util.binary()")
Sat, 15 Feb 2014 19:52:26 +0900 util: add the code path to "cachefunc()" for the function taking no arguments
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 15 Feb 2014 19:52:26 +0900] rev 20835
util: add the code path to "cachefunc()" for the function taking no arguments Before this patch, "util.cachefunc()" caches the value returned by the specified function into dictionary "cache", even if the specified function takes no arguments. In such case, "cache" has at most one entry, and distinction between entries in "cache" is meaningless. This patch adds the code path to "cachefunc()" for the function taking no arguments for efficiency: to store only one cached value, using list "cache" is a little faster than using dictionary "cache".
Wed, 26 Mar 2014 12:52:57 -0500 help: add examples to incoming
Matt Mackall <mpm@selenic.com> [Wed, 26 Mar 2014 12:52:57 -0500] rev 20834
help: add examples to incoming
Tue, 25 Mar 2014 16:10:07 -0700 revset: fix generatorset race condition
Durham Goode <durham@fb.com> [Tue, 25 Mar 2014 16:10:07 -0700] rev 20833
revset: fix generatorset race condition If two things were iterating over a generatorset at the same time, they could miss out on the things the other was generating, resulting in incomplete results. This fixes it by making it possible for two things to iterate at once, by always checking the _genlist at the beginning of each iteration. I was only able to repro it with pending changes from my other commits, but they aren't ready yet. So I'm unable to add a test for now.
Tue, 25 Mar 2014 23:07:52 +0100 tests: don't hardcode path to bash interpreter
Olle Lundberg <geek@nerd.sh> [Tue, 25 Mar 2014 23:07:52 +0100] rev 20832
tests: don't hardcode path to bash interpreter Use the env binary to figure out the correct bash to use. Certain systems ships with an ancient version of bash, but the user might have installed a newer one that is earlier in $PATH. For example the current version of Mac OS X ships version 3.2.51 of bash, which does not understand new fancy builtins such as readarray. A user might install a newer version of bash, use that as their shell and add that path before bin.
Wed, 26 Mar 2014 11:59:13 +0100 contrib: don't hardcode path to bash interpreter
Olle Lundberg <geek@nerd.sh> [Wed, 26 Mar 2014 11:59:13 +0100] rev 20831
contrib: don't hardcode path to bash interpreter Use the env binary to figure out the correct bash to use. Certain systems ships with an ancient version of bash, but the user might have installed a newer one that is earlier in $PATH. For example the current version of Mac OS X ships version 3.2.51 of bash, which does not understand new fancy builtins such as readarray. A user might install a newer version of bash, use that as their shell and add that path before bin.
Tue, 25 Mar 2014 23:10:15 +0100 contrib: explicitly enable perf extension for revset tests
Olle Lundberg <geek@nerd.sh> [Tue, 25 Mar 2014 23:10:15 +0100] rev 20830
contrib: explicitly enable perf extension for revset tests If a developer doesn't have the perf extension enabled the revset benchmarking will fail. This patch explicitly enables the perf extension when running the tests.
Tue, 25 Mar 2014 16:17:16 -0500 merge with stable
Matt Mackall <mpm@selenic.com> [Tue, 25 Mar 2014 16:17:16 -0500] rev 20829
merge with stable
Mon, 24 Mar 2014 20:00:18 -0700 revset: improve performance of _generatorset.__contains__ (issue 4201)
Gregory Szorc <gregory.szorc@gmail.com> [Mon, 24 Mar 2014 20:00:18 -0700] rev 20828
revset: improve performance of _generatorset.__contains__ (issue 4201) _generatorset.__contains__ and __contains__ from child classes were calling into __iter__ to look for values. Since all previously-encountered values from the generator were cached and checked in __contains__ before this iteration, __contains__ was effectively performing iteration busy work which could lead to an explosion of redundant work. This patch changes __contains__ to be more intelligent. Instead of looking at all values via __iter__, __contains__ will instead go straight to "new" values from the underlying generator. On a clone of the Firefox repository with around 200,000 changesets, this patch decreases the execution time of the revset '::(200067)::' from ~100s to ~4s on the author's machine. Rebase operations (which use the aforementioned revset), speed up accordingly.
Sat, 22 Mar 2014 23:39:51 +0900 localrepo: omit ".hgsubstate" also from "added" files
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 22 Mar 2014 23:39:51 +0900] rev 20827
localrepo: omit ".hgsubstate" also from "added" files Before this patch, "localrepository.commit()" omits ".hgsubstate" from "modified" (changes[0]) and "removed" (changes[2]) file list before checking subrepositories, but leaves one in "added" (changes[1]) as it is. Then, "localrepository.commit()" adds ".hgsubstate" into "modified" or "removed" list forcibly, according to subrepository statuses. If "added" contains ".hgsubstate", the committed context will contain two ".hgsubstate" in its "files": one from "added" (not omitted one), and another from "modified" or "removed" (newly added one). How many times ".hgsubstate" appears in "files" changes node hash, even though revision content is same, because node hash calculation uses the specified "files" directly (without duplication check or so). This means that node hash of committed revision changes according to existence of ".hgsubstate" in "added" at "localrepository.commit()". ".hgsubstate" is treated as "added", not only in accidental cases, but also in the case of "qpush" for the patch adding ".hgsubstate". This patch omits ".hgsubstate" also from "added" files before checking subrepositories. This patch also omits ".hgsubstate" exclusion in "qnew"/"qrefresh" introduced by changeset d666da075b91, because this patch makes them meaningless. "hg parents --template '{files}\n'" newly added to "test-mq-subrepo.t" enhances checking unexpected multiple appearances of ".hgsubstate" in "files" of created/refreshed MQ revisions.
(0) -10000 -3000 -1000 -300 -100 -15 +15 +100 +300 +1000 +3000 +10000 +30000 tip