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.
Mon, 24 Oct 2016 09:14:34 -0500 merge with i18n stable
Kevin Bullock <kbullock+mercurial@ringworld.org> [Mon, 24 Oct 2016 09:14:34 -0500] rev 30226
merge with i18n
Sat, 22 Oct 2016 23:18:43 -0200 i18n-pt_BR: synchronized with 7b428b00a1d4 stable
Wagner Bruna <wbruna@yahoo.com> [Sat, 22 Oct 2016 23:18:43 -0200] rev 30225
i18n-pt_BR: synchronized with 7b428b00a1d4
Tue, 18 Oct 2016 16:52:35 +0200 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 30224
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.)
Fri, 21 Oct 2016 16:31:16 +0100 tests: fix test-casefolding.t stable
Simon Farnsworth <simonfar@fb.com> [Fri, 21 Oct 2016 16:31:16 +0100] rev 30223
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.
Wed, 19 Oct 2016 15:07:11 -0700 commands: print security protocol support in debuginstall stable
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 19 Oct 2016 15:07:11 -0700] rev 30222
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -7 +7 +10 +30 +100 +300 +1000 +3000 +10000 tip