Sat, 29 Oct 2016 02:44:45 +0900 tests: invoke printenv.py via sh -c for test portability stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sat, 29 Oct 2016 02:44:45 +0900] rev 30234
tests: invoke printenv.py via sh -c for test portability On Windows platform, invoking printenv.py directly via hook is problematic, because: - unless binding between *.py suffix and python runtime, application selector dialog is displayed, and running test is blocked at each printenv.py invocations - it isn't safe to assume binding between *.py suffix and python runtime, because application binding is easily broken For example, installing IDE (VisualStudio with Python Tools, or so) often requires binding between source files and IDE itself. This patch invokes printenv.py via sh -c for test portability. This is a kind of follow up for d19787db6fe0, which eliminated explicit "python" for printenv.py. There are already other 'sh -c "printenv.py"' in *.t files, and this fix should be reasonable. This changes were confirmed in cases below: - without any application binding for *.py suffix - with binding between *.py suffix and VisualStudio This patch also replaces "echo + redirection" style with "heredoc" style, because: - hook command line is parsed by cmd.exe as shell at first, and - single quotation can't quote arguments on cmd.exe, therefore, - "printenv.py foobar" should be quoted by double quotation, but - nested quoting (or tricky escaping) isn't readable
Thu, 27 Oct 2016 20:06:33 +0200 largefiles: handle that a found standin file doesn't exist when removing it stable
Mads Kiilerich <madski@unity3d.com> [Thu, 27 Oct 2016 20:06:33 +0200] rev 30233
largefiles: handle that a found standin file doesn't exist when removing it I somehow ended up in a situation where hg crashed on an unlink I introduced in 328545c7d8a1. I don't know how it happened and can't reproduce it. It seems like it only can happen when the file is removed between the time of check in a working directory context walk that finds a standin file, and the time of use when we try to remove it because the corresponding largefile doesn't exist. But better safe than sorry: replace the plain unlink with unlinkpath with ignoremissing=True. That will also remove remaining empty directories, which arguably is more correct.
Tue, 25 Oct 2016 21:49:30 +0900 templater: use unfiltered changelog to calculate shortest() at constant time stable
Yuya Nishihara <yuya@tcha.org> [Tue, 25 Oct 2016 21:49:30 +0900] rev 30232
templater: use unfiltered changelog to calculate shortest() at constant time cl._partialmatch() can be pretty slow if hidden revisions are involved. This patch cancels the slowdown introduced by the previous patch by using an unfiltered changelog, which means shortest(node) isn't always the shortest. The result isn't perfect, but seems okay as long as shortest(node) is short enough to type and can be used as an identifier. (with hidden revisions) % hg log -R hg-committed -r0:20000 -T '{node|shortest}\n' --time > /dev/null (.^^) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000) (.^) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000) (.) time: real 1.680 secs (user 1.650+0.000 sys 0.020+0.000)
Sun, 23 Oct 2016 14:05:23 +0900 templater: do not use index.partialmatch() directly to calculate shortest() stable
Yuya Nishihara <yuya@tcha.org> [Sun, 23 Oct 2016 14:05:23 +0900] rev 30231
templater: do not use index.partialmatch() directly to calculate shortest() cl.index.partialmatch() isn't a drop-in replacement for cl._partialmatch(). It has no knowledge about hidden revisions, and it raises ValueError if a node shorter than 4 chars is given. Instead, use index.partialmatch() through cl._partialmatch(), which has no such problems and gives the identical result with/without --pure. The test output was sampled with --pure without this patch, which shows the most correct result. However, we'll need to switch to using an unfiltered changelog because _partialmatch() of a filtered changelog can be an order of magnitude slower. (with hidden revisions) % hg log -R hg-committed -r0:20000 -T '{node|shortest}\n' --time > /dev/null (.^) time: real 1.530 secs (user 1.480+0.000 sys 0.040+0.000) (.) time: real 43.080 secs (user 43.060+0.000 sys 0.030+0.000)
Wed, 26 Oct 2016 22:50:06 +0900 tests: run "cwd was removed" test only if cwd can actually be removed stable
Yuya Nishihara <yuya@tcha.org> [Wed, 26 Oct 2016 22:50:06 +0900] rev 30230
tests: run "cwd was removed" test only if cwd can actually be removed On some platforms, cwd can't be removed. In which case, util.unlinkpath() continues with no error since the failure of directory removal isn't critical. So it doesn't make sense to run the test added by 90a6c18a7c1d on those platforms. OTOH, we need to run the test in test-rebase-scenario-global.t since the repository is referenced after that.
Tue, 25 Oct 2016 21:01:53 +0200 merge: avoid superfluous filemerges when grafting through renames (issue5407) stable
Gábor Stefanik <gabor.stefanik@nng.com> [Tue, 25 Oct 2016 21:01:53 +0200] rev 30229
merge: avoid superfluous filemerges when grafting through renames (issue5407) This is a fix for a regression introduced by the patches for issue4028. The test changes are due to us doing fewer _checkcopies searches now, which makes some test outputs revert to the pre-issue4028 behavior. That issue itself remains fixed, we only skip copy tracing for files where it isn't relevant. As a nice side effect, this makes copy detection much faster when tracing backwards through lots of renames.
Wed, 19 Oct 2016 18:06:14 +0200 sslutil: guard against broken certifi installations (issue5406) stable
Gábor Stefanik <gabor.stefanik@nng.com> [Wed, 19 Oct 2016 18:06:14 +0200] rev 30228
sslutil: guard against broken certifi installations (issue5406) Certifi is currently incompatible with py2exe; the Python code for certifi gets included in library.zip, but not the cacert.pem file - and even if it were included, SSLContext can't load a cacert.pem file from library.zip. This currently makes it impossible to build a standalone Windows version of Mercurial. Guard against this, and possibly other situations where a module with the name "certifi" exists, but is not usable.
Tue, 25 Oct 2016 18:56:27 +0200 revset: don't cache abstractsmartset min/max invocations infinitely stable
Mads Kiilerich <madski@unity3d.com> [Tue, 25 Oct 2016 18:56:27 +0200] rev 30227
revset: don't cache abstractsmartset min/max invocations infinitely There was a "leak", apparently introduced in ab66c1dee405. When running: hg = hglib.open('repo') while True: hg.log("max(branch('default'))") all filteredset instances from branch() would be cached indefinitely by the @util.cachefunc annotation on the max() implementation. util.cachefunc seems dangerous as method decorator and is barely used elsewhere in the code base. Instead, just open code caching by having the min/max methods replace themselves with a plain lambda returning the result.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip