Wed, 15 Oct 2014 17:17:12 -0700 histedit: add histedit state class
David Soria Parra <davidsp@fb.com> [Wed, 15 Oct 2014 17:17:12 -0700] rev 22976
histedit: add histedit state class Add an histeditstate class that is intended to hold the current state. This allows us encapsulate the state and avoids passing around a tuple which is based on the serialization format. In particular this will give actions more control over the state and allow external sources to have more control of histedits behavior, e.g. an external implementation of x/exec.
Fri, 17 Oct 2014 02:07:05 +0900 import-checker: check modules for pure Python build correctly
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Fri, 17 Oct 2014 02:07:05 +0900] rev 22975
import-checker: check modules for pure Python build correctly Before this patch, "import-checker.py" just replaces "/" in specified filenames by ".". This makes modules for pure Python build belong to "mercurial.pure" package, and prevents "import-checker.py" from correctly checking about cyclic dependency in them. This patch discards "pure" component from fully qualified name of such modules. To avoid discarding "pure" from the module name of standard libraries unexpectedly, this patch allows "dotted_name_of_path" to discard "pure" only from Mercurial specific modules, which are specified via command line arguments.
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.
Tue, 14 Oct 2014 00:06:46 -0700 changegroup: store source and url in the `hookargs` dict
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:06:46 -0700] rev 22971
changegroup: store source and url in the `hookargs` dict We store the source and url of the current data into `transaction.hookargs` this let us inherit it from upper layers that may have created a much wider transaction. We have to modify bundle2 at the same time to register the source and url in the transaction. We have to do it in the same patch otherwise, the `addchangegroup` call would fill these values and the hook calling will crash because of the duplicated 'source' and 'url' arguments passed to the hook call.
Tue, 14 Oct 2014 00:43:20 -0700 prechangegroup: use hook argument from the transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:43:20 -0700] rev 22970
prechangegroup: use hook argument from the transaction There can be useful data in there (eg: bundle2 related one)
Tue, 14 Oct 2014 00:09:25 -0700 addchangegroup: call `prechangegroup` hook after transaction retrieval
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:09:25 -0700] rev 22969
addchangegroup: call `prechangegroup` hook after transaction retrieval We want to reused some possible information stored in the transaction `hookargs` dict that may be stored by something handling the transaction at an upper level (eg: bundle2) So we move the running of the hooks after transaction creation. This has no visible effects (but an empty transaction roolback if the hook fails) because nothing had happened in the transaction yet.
Tue, 14 Oct 2014 00:03:03 -0700 addchangegroup: get the `node` argument of `incoming` hook from transaction
Pierre-Yves David <pierre-yves.david@fb.com> [Tue, 14 Oct 2014 00:03:03 -0700] rev 22968
addchangegroup: get the `node` argument of `incoming` hook from transaction The transaction is now carrying hook-related informations. So we use it to retrieve the `node` argument. This will also carry around all kinds of other useful informations (like: "are we in a bundle2 processing")
Tue, 14 Oct 2014 23:53:35 -0700 dicthelpers: delete now that they are no longer used
Martin von Zweigbergk <martinvonz@gmail.com> [Tue, 14 Oct 2014 23:53:35 -0700] rev 22967
dicthelpers: delete now that they are no longer used
(0) -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip