Fri, 17 Oct 2014 02:07:05 +0900 import-checker: treat "from mercurial import XXXX" style correctly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 17 Oct 2014 02:07:05 +0900] rev 22974
import-checker: treat "from mercurial import XXXX" style correctly Before this patch, "import-checker.py" assumes that the name of Mercurial module recognized by "imported_modules" doesn't have package part: for example, "util". This is reason why "import-checker.py" always builds fully qualified module name up relatively, if the given module doesn't belong to standard Python library. But in fact, modules imported in "from mercurial import XXXX" style already have fully qualified name: for example, "mercurial.util" module imported by "mercurial.parsers" is treated as "mercurial.mercurial.util" because of building module name up relatively. This prevents "import-checker.py" from correctly checking about cyclic dependency in them. This patch avoids building module name up relatively, also if module name starts with "mercurial.", to treat modules imported in "from mercurial import XXXX" style correctly.
Fri, 17 Oct 2014 02:07:04 +0900 encoding: avoid cyclic dependency around "parsers" in pure Python build
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 17 Oct 2014 02:07:04 +0900] rev 22973
encoding: avoid cyclic dependency around "parsers" in pure Python build 80f2b63dd83a brought "asciilower" and "import parsers" into "encoding.py". This works fine with "parsers" module in C implementation, but doesn't with one in pure Python implementation, because the latter causes cyclic dependency below and aborting execution: util => i18n => encoding => parsers => util This patch delays importing "parsers" module until it is really needed, to avoid cyclic dependency around "parsers" in pure Python build.
Tue, 14 Oct 2014 01:40:04 -0700 pull: add source information to the transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 01:40:04 -0700] rev 22972
pull: add source information to the transaction The source information can, should be applied once when opening the transaction for the pull. This will lets element processed within a bundle2 be aware of them and open the door to running a set of hooks when closing this pull transaction. This is similar to what is done in server's unbundle call.
(0) -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 +10000 tip