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")

--HG--
extra : rebase_source : 4fe338a21e21903164fddacec40e1af9244a2f4a
extra : amend_source : 0b3a2d7401958dfbb4b60f887777d4c9b250e37b
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.

--HG--
extra : rebase_source : df8aa2205ec6f0f3685fbed047e1ec2767231b09
prechangegroup: use hook argument from the transaction

There can be useful data in there (eg: bundle2 related one)

--HG--
extra : rebase_source : 2853a517cb4e882951f8ef0406039c496ddc4271
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.

--HG--
extra : rebase_source : a0312783c77b58aa1f8c011163e4bd4ae1794445
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.

--HG--
extra : rebase_source : 4d992e70ad166ae5a98c2f7c7ba242829da59582
extra : amend_source : 7cf73dc6c576e11a6746eb087aa3043a8ae02977
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.

--HG--
extra : rebase_source : ac1c3f576de8c2a5eeb17486618502f9fe8c96f2
extra : source : ec836177793e2967662313420a7c07d6e1e940dc
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.

--HG--
extra : rebase_source : 0f04a589de45ac92ea603c98dd1d0c4e38471212
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.

--HG--
extra : rebase_source : ec464a1d89653f846170fc9b85852f9fced33dc2
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.

--HG--
extra : rebase_source : 062a8a89a1272b65a3eb20deeeed4f38a6e3f140
histedit: use state object where necessary

We are using the properties from the state object where necessary and
ensure that the state is set correctly.

--HG--
extra : rebase_source : c6f226a9c149ffede8a3a8873ed5697da017e61d
histedit: add clear method to remove state

Encapsulate the unlinking histedit-state and use the vfs layer instead of
os.unlink.

--HG--
extra : rebase_source : 3b6c9aab2b0036d62cf91ead02f714c7d444d937
histedit: let the state expose a context but serialize correctly to nodes

The histedit code often expects a context. However histedit hands
around the tuple for the serialization and therefore hand over a
parentctxnode. This leads to code having to return a context based
on the parentctxnode. We let the state only return a context but
correctly serialize and deserialze to a node.

--HG--
extra : rebase_source : 75faa46efb356f6da04964affa0650025bed7a45
histedit: pass state to boostrapcontinue

Pass the state to boostrapcontinue and remove the unecessary passing
of repo.

--HG--
extra : rebase_source : 7fe467b682bdcbd396236c621be294c6b53f6218
histedit: pass state to processreplacement

--HG--
extra : rebase_source : 9614179cb0189c087c32c780a6e2d34adc3fbbac
histedit: pass state to action functions

--HG--
extra : rebase_source : 1a483e242567bd80fb4447d7e5f15ebf8a53318f
histedit: read state from histeditstate

Read the state in histeditstate. This allows us to correctly update
internal variables when necessary without having to recreate a new
state.  When we read a state in _histedit state while we will already
have state passed from histedit(), we can read the state in place
and don't have to merge two histeditstates.

--HG--
extra : rebase_source : f20f05ce0ca0071fd1d9f695773fe50bed63def5
histedit: move locks into state

Allow action functions to control the locks. This is necessary for
an implementation of x/exec or similar.

--HG--
extra : rebase_source : 89e1a3a6ac219bdb6ac1d27de8375686fda8c352
histedit: remove now-superfluous repo argument from processreplacement

Spotted by Olle on the mailing list during review.

--HG--
extra : rebase_source : 4992b496cb7d91c900f4412f1ee22418924a1f30
histedit: update docstring on histeditstate.read()

The docstring showed the previous class-less heritage of read(). Now
that it's classy, update the docstring.

--HG--
extra : rebase_source : 406a4be244bea8ddaf95bac6555c91a15756390a
histedit: miscellaneous style cleanups

Fix some mis-wrapped lines, re-wrap some lines to be more compact,
remove superfluous parens.

--HG--
extra : rebase_source : 3a260da61ed5de53918c91a5cadcf705f8da8ef3