Mon, 01 Aug 2016 08:27:22 +0900 i18n-ja: synchronized with 6fd751fa58d3 stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 08:27:22 +0900] rev 29643
i18n-ja: synchronized with 6fd751fa58d3
Sun, 31 Jul 2016 05:39:59 +0900 demandimport: avoid infinite recursion at actual module importing (issue5304) stable
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Sun, 31 Jul 2016 05:39:59 +0900] rev 29642
demandimport: avoid infinite recursion at actual module importing (issue5304) Before this patch, importing C module on Windows environment causes infinite recursion call, if py2exe is used with -b2 option. At importing C module "a.b", extra hooking by zipextimporter of py2exe causes: 0. assumption before accessing "b" of "a": - built-in module object is created for "a", (= "a" is actually imported) - _demandmod is created for "a.b" as a proxy object, and (= "a.b" is not yet imported) - an attribute "b" of "a" is initialized by the latter 1. invocation of __import__ via _hgextimport() in _demandmod._load() for "a.b" implies _demandimport() for "a.b" This is unintentional, because _demandmod might be returned by _hgextimport() instead of built-in module object. 2. _demandimport() at (1) is invoked with not context of "a", but context of zipextimporter Just after invocation of _hgextimport() in _demandimport(), an attribute "b" of the built-in module object for "a" is still bound to the proxy object for "a.b", because context of "a" isn't updated by actual importing "a.b". even though the built-in module object for "a.b" already appears in sys.modules. Therefore, chainmodules() returns _demandmod for "a.b", which is gotten from the attribute "b" of "a". 3. processfromitem() on "a.b" causes _demandmod._load() for "a.b" again _demandimport() takes context of "a" in this case. Therefore, attributes below are bound to built-in module object for "a.b", as expected: - "b" of built-in module object for "a" - _module of _demandmod for "a.b" 4. but _demandimport() invoked at (1) returns _demandmod object because _demandimport() just returns the object returned by chainmodules() at (3) above. 5. then, _demandmod._load() causes infinite recursion call _demandimport() returns _demandmod for "a.b", and it is "self" at _demandmod._load(). To avoid infinite recursion at actual module importing, this patch uses self._module, if _hgextimport() returns _demandmod itself. If _demandmod._module isn't yet bound at this point, execution should be aborted, because actual importing failed. In this patch, _demandmod._module is examined not on _demandimport() side, but on _demandmod._load() side, because: - the former has some exit points - only the latter uses _hgextimport(), except for _demandimport() BTW, this issue occurs only in the code path for non .py/.pyc files in zipextimporter (strictly speaking, in _memimporter) of py2exe. Even if zipextimporter is enabled, .py/.pyc files are handled by zipimporter, and it doesn't imply unintentional _demandimport() at invocation of __import__ via _hgextimport().
Fri, 29 Jul 2016 00:45:24 +0200 packagelib: do not remove packages directory in hggetversion (issue5262) stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 29 Jul 2016 00:45:24 +0200] rev 29641
packagelib: do not remove packages directory in hggetversion (issue5262) People running packages related code probably do care about the content of this directory. In particular this shound fix the rpm builder process.
Fri, 29 Jul 2016 00:39:59 +0200 make: introduce a target to clean everything but packages stable
Pierre-Yves David <pierre-yves.david@ens-lyon.org> [Fri, 29 Jul 2016 00:39:59 +0200] rev 29640
make: introduce a target to clean everything but packages Removing the 'packages' directory makes nightly builder life much harder.
Fri, 29 Jul 2016 12:46:07 +0100 url: avoid re-issuing incorrect password (issue3210) stable
Kim Randell <Kim.Randell@vicon.com> [Fri, 29 Jul 2016 12:46:07 +0100] rev 29639
url: avoid re-issuing incorrect password (issue3210) Some draconian IT setups lock accounts after a small number of incorrect password attempts. Mercurial's implementation of the urllib2 authentication was causing 5 retry attempts with the same credentials, without prompting the user. The code was attempting to check whether the authorization token had changed, but unfortunately was reading the misleading 'headers' member of the request instead of using the 'get_header' accessor. Modelled on fix for Python issue 8797: https://bugs.python.org/issue8797 https://hg.python.org/cpython/rev/30e8a8f22a2a
Wed, 27 Jul 2016 15:22:36 -0500 date: accept broader range of ISO 8601 time specs stable
Matt Mackall <mpm@selenic.com> [Wed, 27 Jul 2016 15:22:36 -0500] rev 29638
date: accept broader range of ISO 8601 time specs The "normal" ISO date/time includes a T between date and time. It also allows dropping the colons and seconds from the timespec. Add new patterns for these forms as well as tests.
Wed, 27 Jul 2016 15:20:34 -0500 date: parse ISO-style Z and +hh:mm timezone specs stable
Matt Mackall <mpm@selenic.com> [Wed, 27 Jul 2016 15:20:34 -0500] rev 29637
date: parse ISO-style Z and +hh:mm timezone specs
Wed, 27 Jul 2016 15:14:19 -0500 date: refactor timezone parsing stable
Matt Mackall <mpm@selenic.com> [Wed, 27 Jul 2016 15:14:19 -0500] rev 29636
date: refactor timezone parsing We want to be able to accept ISO 8601 style timezones that don't include a space separator, so we change the timezone parsing function to accept a full date string and return both the offset and the non-timezone portion.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -8 +8 +10 +30 +100 +300 +1000 +3000 +10000 tip