tests: fix pyflakes test whitespace breakage

pushkey: wrap pushkey phase movement in a transaction Phases are not yet inside the transaction, but we need to prepare for it. So we wrap the phase movement inside a transaction.

push: wrap local phase movement in a transaction Phases are not yet inside the transaction, but we need to prepare for it. So we wrap the phase movement inside a transaction.

phase: wrap `hg phases` phase movement in a transaction Phases are not yet inside the transaction, but we need to prepare for it. So we wrap the phase movement inside a transaction.

mq: wrap qimport phase movement in a transaction Phases are not yet inside the transaction, but we need to prepare for it. So we wrap the phase movement inside a transaction.

mq: wrap qfinish phase movement in a transaction Phases are not yet inside the transaction, but we need to prepare for it. So we wrap the phase movement inside a transaction.

tests: change some #ifs to #requires

tests: replace exit 80 with #require

run-tests: add #require to abort full test This allows nuking a bunch of ugly hghave || exit 80 lines.

run-tests: add support for xunit test reports The Jenkins CI system understands xunit reports natively, so this will be helpful for anyone that wants to use Jenkins for testing hg or extensions that use run-tests.py for their testing.

contrib: add check-commit hook script to sanity-check commits

shelve: use `targetphase` while unbundling This removes the last manual phase movement in shelve.

changegroup: add a `targetphase` argument to `addchangegroup` This argument controls the phase used for the added changesets. This can be useful to unbundle in "secret" phase as required by shelve. This change aims at helping high-level code get rid of manual phase movement. An important milestone for having phases part of the transaction.

shelve: do not retract phase boundary by hand We rely on the internal mechanism to commit the changeset in the right state. This is similar to what the mq extension is doing. This is an important change as we plan to move phase movement with the transaction. Avoiding phase movement from high level code will avoid them the burden of transaction handling. It is also important to limit the need for transaction handling as this limits the odds of people messing up. Most common expected mess-up is to use a different transaction for changesets creation and phase adjustment.

commit: update the --secret code to use backupconfig and restoreconfig Those dedicated methods also preserve all associated data (eg: sources, lack of value).

rebase: do not retract phase boundary by hand We rely on the internal mechanism to commit the changeset in the right phase. This similar to what the mq extension is doing. This is an important change as we plan to includes phase movement within the transaction. Avoiding phase movement from high-level code will avoid the burden of transaction handling. It is also important to limit the need for transaction handling as this limits the odds of people messing up. Most common expected mess-up is code using a different transaction for changeset creation and phase adjustment.

config: fix restoreconfig of non existing config When the section, but no value existed, the `del` call raised a key error.

push: use stepsdone for obsmarkers push We do not have infrastructure to include obsolescence markers in the bundle2 push from core. But extensions may so we make sure it would not be sent twice.

push: introduce a discovery step for obsmarker The discovery step is still not doing anything smart. But this will allow extension to wrap it.

push: move the list of obsmarker to push into the push operation The list is now carried in the push operation, this will let extensions override it.

push: explicitly encode a list of obsmarkers to push Sending obsmarkers through pushkey requires extra encoding (since pushkey can't take binary content) and slicing (since we can hit http header limit). As we send all obsolescences markers that exists in the repo for each push, we used to just look at the content of the "obsolete" pushkey namespace (already encoded and sliced) and send its content. However, future changeset will make it possible to push only parts of the obsmarkers. To prepare this we now explicitly encode a list of markers. The list of markers is still "all of them" but future changeset will takes care of that. The new code uses a "_protected" method but that seems reasonable to keep it private as this is the is the only external user of it and this whole pushing obsmarker through pushkey things in fairly hacky already)

merge-tools: add a `premerge=keep-merge3` config option This value leaves premerge markers that includes the merge base too. This is a the same as what `internal:merge3` would do.

merge-tools: make premerge valid values extensible We want to introduce a version leaving merge3 style markers.

mergetools: add a test for premerge --keep It works! No surprise.

test-merge-tools: introduce a "revision 4" that merges with conflict We need conflicts to test the premerge=keep configuration.

merge: add an internal:merge3 tool This variant gives access to a feature already present in ``internal:merge``: displaying merge base content. In the basic merge (calling ``hg merge``) case, including more context to the merge markers is an interesting addition. But this extra information is the only viable option in case conflict from grafting (, rebase, etc…). When grafting ``source`` on ``destination``, the parent of ``source`` is used as the ``base``. When all three changesets add content in the same location, the marker for ``source`` will contains both ``base`` and ``source`` content. Without the content of base exposed, there is no way for the user to discriminate content coming from ``base`` and content commit from ``source``. Practical example (all addition are in the same place): * ``destination`` adds ``Dest-Content`` * ``base`` adds ``Base-Content`` * ``source`` adds ``Src-Content`` Grafting ``source`` on ``destination`` will produce the following conflict: <<<<<<< destination Dest-Content ======= Base-Content Src-Content >>>>>>> source This that case there is no way to distinct ``base`` from ``source``. As a result content from ``base`` are likely to slip in the resolution result. However, adding the base make the situation very clear: <<<<<<< destination Dest-Content ||||||| base Base-Content ======= base Base-Content Src-Content >>>>>>> source Once the base is added, the addition from the grafted changeset is made clear. User can compare the content from ``base`` and ``source`` to make an enlightened decision during merge resolution.

internal:merge: update documentation Highlight the fact there are two regions in the markers and what their contents are. This prepares for the arrival of merge3.

filemerge: allow the formatting of three labels instead of two When a third label is provided (to included the base content) it is properly processed as the two others. Nothing changes if only two labels are provided.

filemerge: drop extra white space There should be no white space around the brace.

simplemerge: support three labels when merging If a third label is provided it will be used for the "base" content: <<<<<<< local content from local ||||||| base former common ======= other conflicting >>>>>>> other