Augie Fackler <augie@google.com> [Mon, 01 Aug 2016 12:11:56 -0400] rev 29650
merge with i18n
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 06:08:27 +0900] rev 29649
doc: make previous line of certificate example end with "::"
Before this patch, certificate example is formatted just as normal
text.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 06:08:27 +0900] rev 29648
doc: fix incorrect use of rst hg role in help text
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 06:08:26 +0900] rev 29647
doc: use field rst syntax to show keywords in debugdeltachain help correctly
List of available keywords is well formatted as a list of fields in
doc string, but is formatted as just normal text in online help
output.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 06:08:26 +0900] rev 29646
revset: refactor to make xgettext put i18n comments into hg.pot file
xgettext expects both "_()" and (a part of) text to be placed at just
next line of "i18n:" comment.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 06:08:26 +0900] rev 29645
doc: omit useless _() invocation
In this case, column positioning isn't needed for i18n, too.
Maybe, check-code warning "missing _() in ui message" caused this
useless _() invocation in 92d37fb3f1aa.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 06:08:25 +0900] rev 29644
doc: trim newline at the end of exception message
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Mon, 01 Aug 2016 08:27:22 +0900] rev 29643
i18n-ja: synchronized with 6fd751fa58d3
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().
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.