34a5f6c66bc5a13381a68d08f73d858916167836: 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 33727
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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
3afde791dce192f38d8a228ed8e49397e353837e: 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 33726
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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.
362740e054609d55dea1403ce5fdfcb1379403fb: 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 33725
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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)
741e5d7f282da2ce85b13792d86c902ee64fc3c5: 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 33724
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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)
46a0203dfb89a8da48c3b9ae8e842cff9c4ff6ea: 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 33723
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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.
69ffbbe73dd03df0d1a00bdb2bc083fdb73ede09: 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 33722
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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.
b9f7b0c10027764cee77f9c6d61877fcffea837f: sslutil: guard against broken certifi installations (issue5406) stable
Gábor Stefanik <gabor.stefanik@nng.com> - Wed, 19 Oct 2016 18:06:14 +0200 - rev 33721
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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.
5ee944b9c750acce1ae6a8bc6011343499a30a5d: revset: don't cache abstractsmartset min/max invocations infinitely stable
Mads Kiilerich <madski@unity3d.com> - Tue, 25 Oct 2016 18:56:27 +0200 - rev 33720
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
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.
264f00b3e5f045ac5b58d79e2a3976585f4e7739: merge with i18n stable
Kevin Bullock <kbullock+mercurial@ringworld.org> - Mon, 24 Oct 2016 09:14:34 -0500 - rev 33719
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
merge with i18n
7069d3d8a56e34b9d7b36a5c86429361f5473bca: i18n-pt_BR: synchronized with 7b428b00a1d4 stable
Wagner Bruna <wbruna@yahoo.com> - Sat, 22 Oct 2016 23:18:43 -0200 - rev 33718
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
i18n-pt_BR: synchronized with 7b428b00a1d4
ad56071b37d436732d38f23fa52b0f4f9e90e9f2: dirstate: fix debug.dirstate.delaywrite to use the new "now" after sleeping stable
Mads Kiilerich <madski@unity3d.com> - Tue, 18 Oct 2016 16:52:35 +0200 - rev 33717
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
dirstate: fix debug.dirstate.delaywrite to use the new "now" after sleeping It seems like the a regression has sneaked into debug.dirstate.delaywrite in 6c6b48aca328. It would sleep until no files were modified "now" any more, but when writing the dirstate it would use the old "now" and still mark files as 'unset' instead of recording the timestamp that would make the file show up as clean instead of unknown. Instead of getting a new "now" from the file system, we trust the computed end time as the new "now" and thus cause the actual modification time to be writiten to the dirstate. debug.dirstate.delaywrite is undocumented and only used in test-largefiles-update.t . All tests seems to work fine for me without debug.dirstate.delaywrite . Perhaps because it not really worked as intended without the fix in this patch, and code and tests thus have evolved to do fine without it? It could thus perhaps make sense to drop usage of this setting in the tests. That could speed the test up a bit. This functionality (or something very similar) can however apparently be very convenient in setups where checking dirty-ness is expensive - such as when using large files and have slow file filesystems or are CPU constrained. Now it works and we can try it. (But ideally, for the largefile use case, it should probably only delay lfdirstate writes - not ordinary dirstate.)
76c57e1fe79b0980b377b4f305635dea393d6315: tests: fix test-casefolding.t stable
Simon Farnsworth <simonfar@fb.com> - Fri, 21 Oct 2016 16:31:16 +0100 - rev 33716
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
tests: fix test-casefolding.t The message had changed, but the test was not updated. This test does not run on Linux, but failed on my Mac.
7b428b00a1d4e208557d46d207751fb135083097: commands: print security protocol support in debuginstall stable
Gregory Szorc <gregory.szorc@gmail.com> - Wed, 19 Oct 2016 15:07:11 -0700 - rev 33715
Push 365 by gszorc@mozilla.com at Tue, 01 Nov 2016 02:33:44 +0000
commands: print security protocol support in debuginstall Over the past week I've had to instruct multiple people to run Python code to query the ssl module to see what TLS protocol support is present. I think it would be useful for `hg debuginstall` to print this info to make it easier to access and debug why Mercurial is complaining about using an insecure TLS 1.0 protocol. Ideally we'd also print the path to the CA cert bundle. But the APIs for querying that in sslutil can emit warnings, making it slightly more difficult to integrate into `hg debuginstall`. That work will have to wait for another day.
f2c5b9d48b296fd8e9a25e533c770fd46d7c804f: manifest: make treemanifestctx store the repo stable
Durham Goode <durham@fb.com> - Tue, 18 Oct 2016 17:44:42 -0700 - rev 33547
Push 357 by gszorc@mozilla.com at Sat, 22 Oct 2016 21:43:53 +0000
manifest: make treemanifestctx store the repo Same as in the last commit, the old treemanifestctx stored a reference to the revlog. If the inmemory revlog became invalid, the ctx now held an old copy and would be incorrect. To fix this, we need the ctx to go through the manifestlog for each access. This is the same pattern that changectx already uses (it stores the repo, and accesses commit data through self._repo.changelog).
acc8885a6450e5dec5426cddaa87b90a5125111f: manifest: make manifestctx store the repo stable
Durham Goode <durham@fb.com> - Tue, 18 Oct 2016 17:44:26 -0700 - rev 33546
Push 357 by gszorc@mozilla.com at Sat, 22 Oct 2016 21:43:53 +0000
manifest: make manifestctx store the repo The old manifestctx stored a reference to the revlog. If the inmemory revlog became invalid, the ctx now held an old copy and would be incorrect. To fix this, we need the ctx to go through the manifestlog for each access. This is the same pattern that changectx already uses (it stores the repo, and accesses commit data through self._repo.changelog).
3c8811efdddcee3e54632e62af8ebd808220c806: manifest: make manifestlog a storecache stable
Durham Goode <durham@fb.com> - Tue, 18 Oct 2016 17:33:39 -0700 - rev 33545
Push 357 by gszorc@mozilla.com at Sat, 22 Oct 2016 21:43:53 +0000
manifest: make manifestlog a storecache The old @property on manifestlog was broken. It meant that we would always recreate the manifestlog instance, which meant the cache was never hit. Since we'll eventually remove repo.manifest and make manifestlog the only property, let's go ahead and make manifestlog the @storecache property, have manifestlog own the manifest instance, and have repo.manifest refer to it via manifestlog. This means all accesses go through repo.manifestlog, which is now invalidated correctly.
1767723f71cf626ea2b9fa49efee8a7153310527: manifest: move manifest creation to a helper function stable
Durham Goode <durham@fb.com> - Tue, 18 Oct 2016 17:32:51 -0700 - rev 33544
Push 357 by gszorc@mozilla.com at Sat, 22 Oct 2016 21:43:53 +0000
manifest: move manifest creation to a helper function A future patch will be moving manifest creation to be inside manifestlog as part of improving our cache guarantees. bundlerepo and unionrepo currently rely on being able to hook into manifest creation, so let's temporarily move the actual manifest creation to a helper function for them to intercept. In the future manifest.manifest() will disappear entirely and this can disappear.
e478f11e418288b8308457303d3ddf6a23f874f8: Added signature for changeset 438173c41587 stable
Kevin Bullock <kbullock@ringworld.org> - Tue, 18 Oct 2016 14:27:30 -0500 - rev 33541
Push 355 by gszorc@mozilla.com at Wed, 19 Oct 2016 22:16:34 +0000
Added signature for changeset 438173c41587
a314082946f8f58836add399aefb9fe6827028a9: Added tag 4.0-rc for changeset 438173c41587 stable
Kevin Bullock <kbullock@ringworld.org> - Tue, 18 Oct 2016 14:27:25 -0500 - rev 33540
Push 355 by gszorc@mozilla.com at Wed, 19 Oct 2016 22:16:34 +0000
Added tag 4.0-rc for changeset 438173c41587
438173c415874f6ac653efc1099dec9c9150e90f: merge default into stable for 4.0 code freeze stable 4.0-rc
Kevin Bullock <kbullock+mercurial@ringworld.org> - Tue, 18 Oct 2016 14:15:15 -0500 - rev 33539
Push 355 by gszorc@mozilla.com at Wed, 19 Oct 2016 22:16:34 +0000
merge default into stable for 4.0 code freeze
(0) -30000 -10000 -3000 -1000 +10000 tip