Fri, 24 Oct 2014 11:39:39 -0700 util.fspath: use a dict rather than a linear scan for lookups stable
Siddharth Agarwal <sid0@fb.com> [Fri, 24 Oct 2014 11:39:39 -0700] rev 23097
util.fspath: use a dict rather than a linear scan for lookups Previously, we'd scan through the entire directory listing looking for a normalized match. This is O(N) in the number of files in the directory. If we decide to call util.fspath on each file in it, the overall complexity works out to O(N^2). This becomes a problem with directories a few thousand files or larger. Switch to using a dictionary instead. There is a slightly higher upfront cost to pay, but for cases like the above this is amortized O(1). Plus there is a lower constant factor because generator comprehensions are faster than for loops, so overall it works out to be a very small loss in performance for 1 file, and a huge gain when there's more. For a large repo with around 200k files in it on a case-insensitive file system, for a large directory with over 30,000 files in it, the following command was tested: ls | shuf -n $COUNT | xargs hg status This command leads to util.fspath being called on $COUNT files in the directory. COUNT before after 1 0.77s 0.78s 100 1.42s 0.80s 1000 6.3s 0.96s I also tested with COUNT=10000, but before took too long so I gave up.
Mon, 27 Oct 2014 16:53:01 -0500 test-clone.t: drop message about listing bookmarks with no hardlinks stable
Matt Mackall <mpm@selenic.com> [Mon, 27 Oct 2014 16:53:01 -0500] rev 23096
test-clone.t: drop message about listing bookmarks with no hardlinks
Mon, 27 Oct 2014 16:39:57 -0500 tests: don't try to test unix sockets on vfat stable
Matt Mackall <mpm@selenic.com> [Mon, 27 Oct 2014 16:39:57 -0500] rev 23095
tests: don't try to test unix sockets on vfat
Tue, 28 Oct 2014 00:19:18 +0900 tests: change obsolete timestamp to avoid "gmtime()" problem on Windows stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 00:19:18 +0900] rev 23094
tests: change obsolete timestamp to avoid "gmtime()" problem on Windows Before this patch, "test-obsolete.t" fails on Windows environment, because strings corresponded to "tm_wday" (day of the week) field are incorrect. On POSIX environment, "gmtime()" returns correct "tm_wday" value even for negative "time_t" value. On the other hand, it returns incorrect one on Windows environment. At least, "gmtime()" of the Windows runtime library bundled with Python 2.7.3 does. According to 9a7d0f7e0561 introducing original timestamp value '56 120', it shouldn't cause negative "time_t" value. test-obsolete: remove subminute timezone in test Obsmarker format "1" does not supports sub minute timezone. So we change the test to something slightly more sensible. It replaced "-d '56 12'" by "-d '56 120'".
Tue, 28 Oct 2014 00:19:18 +0900 tests: use "%HG_ARGS%" in shell alias on Windows instead of "$HG_ARGS" stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 00:19:18 +0900] rev 23093
tests: use "%HG_ARGS%" in shell alias on Windows instead of "$HG_ARGS" Before this patch, a part of "test-alias.t" fails unexpectedly on Windows environment, because "cmd.exe" can't evaluate "$HG_ARGS" expression in shell alias correctly. This patch uses "%HG_ARGS%" in shell alias on Windows instead of "$HG_ARGS" to expand it correctly.
Tue, 28 Oct 2014 00:19:18 +0900 tests: introduce "checkeditform-n-cat.sh" script to invoke "cat" in it safely stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 00:19:18 +0900] rev 23092
tests: introduce "checkeditform-n-cat.sh" script to invoke "cat" in it safely Before this patch, a part of "test-transplant.t" fails unexpectedly on Windows environment, because semicolon (";") in HGEDITOR isn't recognized as the command separator by "cmd.exe". This patch newly introduces "checkeditform-n-cat.sh" script to invoke "cat" in it safely anywhere.
Fri, 24 Oct 2014 13:50:00 -0400 doc: change 'revision or range' to 'revision or revset' stable
Jordi Gutiérrez Hermoso <jordigh@octave.org> [Fri, 24 Oct 2014 13:50:00 -0400] rev 23091
doc: change 'revision or range' to 'revision or revset' The phrase "revision or range" comes from a pre-revset era. Since the documentation for ranges now is under the revset docs, and as a helpful hint nudging users towards revsets, I think it's better to say "revision or revset"
Tue, 28 Oct 2014 01:14:12 +0900 largefiles: add examination of exec bit in "hg status --rev REV" case stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 01:14:12 +0900] rev 23090
largefiles: add examination of exec bit in "hg status --rev REV" case Before this patch, "hg status --rev REV" doesn't list largefiles up with "M" mark, even if exec bit of them is changed, because "lfilesrepo.status" doesn't examine exec bit in such case.
Tue, 28 Oct 2014 01:14:11 +0900 largefiles: ignore removal status of files not managed in the target context stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Tue, 28 Oct 2014 01:14:11 +0900] rev 23089
largefiles: ignore removal status of files not managed in the target context Before this patch, "hg status --rev REV" listed largefiles removed in the working directory up with "R" mark, even if they aren't managed in the REV. Normal files aren't listed up in such case. When "lfilesrepo.status" is invoked for "hg status --rev REV", it treats files on conditions below as "removed" (to avoid manifest full scan in "ctx.status" ?): - marked as "R" in lfdirstate, or - files managed in the target revision but unknown in the manifest of the working context (= not including "R" files) But the former can include files not managed in the target context. To ignore removal status of files not managed in the target context, this patch drops files unknown in the target revision from "removed" list.
Sun, 26 Oct 2014 12:14:12 +0100 changelog: use headrevsfiltered stable
Mads Kiilerich <madski@unity3d.com> [Sun, 26 Oct 2014 12:14:12 +0100] rev 23088
changelog: use headrevsfiltered 2b5940f64750 introduced use of the new filtering headrevs C implementation. It caught TypeError to detect when to fall back to the implementation that was compatible with old extensions. That method was however not reliable. Instead, use the new headrevsfiltered function when passing a filter. It will reliably fail with AttributeError when an old extension that predates headrevsfiltered is used.
Sun, 26 Oct 2014 12:14:10 +0100 parsers: introduce headrevsfiltered in C extension stable
Mads Kiilerich <madski@unity3d.com> [Sun, 26 Oct 2014 12:14:10 +0100] rev 23087
parsers: introduce headrevsfiltered in C extension All extensions that have this function do support filtering. The existing headrevs function may support filtering but we cannot reliably detect whether it does.
Sat, 25 Oct 2014 21:34:49 -0400 httppeer: close the temporary bundle file after two-way streaming it stable
Matt Harbison <matt_harbison@yahoo.com> [Sat, 25 Oct 2014 21:34:49 -0400] rev 23086
httppeer: close the temporary bundle file after two-way streaming it This fixes several push tests in test-bundle2-exchange.t that were failing on Windows with messages like the following: $ hg -R main push http://localhost:$HGPORT2/ -r 32af7686d403 \ --bookmark book_32af pushing to http://localhost:$HGPORT2/ searching for changes remote: adding changesets remote: adding manifests remote: adding file changes remote: added 1 changesets with 1 changes to 1 files remote: 1 new obsolescence markers updating bookmark book_32af abort: The process cannot access the file because it is being used by another process: 'C:\path\to\tmp\bundle.hg' [255]
Fri, 24 Oct 2014 14:24:28 -0700 status: make 'hg status --rev' faster when there are deleted files stable
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Oct 2014 14:24:28 -0700] rev 23085
status: make 'hg status --rev' faster when there are deleted files In order not to avoid listing files as both added and deleted, for example, we check for every file in the manifest if it is in the _list_ of deleted files. This can get quite slow when there are many deleted files. Change it to a set to make the containment check faster. On a somewhat contrived example of the Mozilla repo with the entire testing/ directory deleted (~14k files), this makes 'hg status --rev .^' go from 26s to 2s.
Mon, 27 Oct 2014 17:52:33 +0100 setdiscovery: limit the size of the initial sample (issue4411) stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 27 Oct 2014 17:52:33 +0100] rev 23084
setdiscovery: limit the size of the initial sample (issue4411) The set discovery start by sending a "known" command with all local heads. When the number of local heads is massive (eg: using hidden changesets) such request becomes too large. This lead to 414 error over http, aborting the whole process. We limit the size of the sample used by the first query to fix this. The test are impacted because they do test massive number of heads. But they do not test it over real world http setup.
Mon, 27 Oct 2014 17:40:32 +0100 setdiscovery: extract sample limitation in a `_limitsample` function stable
Pierre-Yves David <pierre-yves.david@fb.com> [Mon, 27 Oct 2014 17:40:32 +0100] rev 23083
setdiscovery: extract sample limitation in a `_limitsample` function We need to reuse this logic for the initial query. We extract it in a function to unsure sample limiting is applied consistently in all cases.
Fri, 24 Oct 2014 17:24:46 -0500 exchange: don't report failure from identical bookmarks stable
Gregory Szorc <gregory.szorc@gmail.com> [Fri, 24 Oct 2014 17:24:46 -0500] rev 23082
exchange: don't report failure from identical bookmarks b901645a8784 regressed the behavior of pushing an unchanged bookmark to a remote. Before that commit, pushing a unchanged bookmark would result in "exporting bookmark @" being printed. After that commit, we now see an incorrect message "bookmark %s does not exist on the local or remote repository!" This patch fixes the regression introduced by b901645a8784 by having the bookmark error reporting code filter identical bookmarks and adds a test for the behavior.
(0) -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 +3000 +10000 tip