tests: fixup issue markers to make check-commit happy

--HG--
extra : histedit_source : c313b6f92d78bbb48563d5fdea74770f941e51be
unshelve: silence internal revert

This prepares for upcoming revert changes.

--HG--
extra : amend_source : 62e34029eba5cc06ac06d96010513fc1db556f8a
revert: triage "deleted" files into more appropriate categories

Status can return file as "deleted". This is only a special case
related to working directory state: file is recorded as tracked but no
file exists on disk. This will never be a state obtainable from
manifest comparisons.

"Deleted" files have another working directory status shadowed by the lack of
file. They will -alway- be touched by revert. The "lack of file" can be seen as
a modification. The file will never match the same "content" as in the revert
target. From there we have two options:

1. The file exists in the target and can be seen as "modified".
2. The file does not exist in the target and can be seen as "added".

So now we just dispatch elements from delete into appropriate categories.

--HG--
extra : rebase_source : afc561ff418a2d78534c538e3b42feb945e02261
revert: also track clean files

Tracking clean files is the simplest way to be able to reports files that need
no changes. So we explicitly retrieve them.

This fixes a couple of test outputs where the lack of changes was not reported.

--HG--
extra : rebase_source : 80bfd673ea3552b533ce2c43e5aa11b147136714
extra : amend_source : 87649c339f9ad99c6d59addc499a031f034958fe
revert: process removed files missing in target as clean

If a file does not exist in target and is marked as removed in the dirstate, we
can mark it as clean. There are no changes needed to revert it.
revert: use "remove" information from both statuses

Using status information against the target to make sure we are catching all
files that need to be re-added.

We still need to distinguish fresh removal because they use a different
message.
revert: drop special case handling for file unknown in parent

We had a special case for file not caught by any categories. It was
aimed at files missing in wc and wc's parent but existing in the target
revision. This is now properly handled using status information.
revert: use modified information from both statuses

Using status information against the target ensures we are catching all
files with modifications that need reverting.

We still need to distinguish fresh modifications for backup purpose.

test-largefile is affected because it reverted a file that needs no content
change.

--HG--
extra : amend_source : b2e93588f91ee93b5d6e6799ca59128460341102
debugobsolete: catch ValueError that may be raised by obsstore.create

There are already a couple of errors that obsstore.create can raise and we are
going to introduce a cycle check too.

--HG--
branch : stable
obsstore.create: add a simple safeguard against cyclic markers

We detect when there is a cycle in the marker itself (precursors being listed
as successors).

--HG--
branch : stable
discovery: prevent crash on unknown remote heads with old repo (issue4337)

When a remote is not capable of the `branchmap` wireproto command, we denote
incoming heads with None. This leads to a crash in the code in charge of
displaying the list of unknown remote heads.

We now properly detect this case and display a shorter message in this case.

The reason for this  `set([None])` value is now documented.

--HG--
branch : stable
merge: show the scary multiple ancestor hint for merges only, not for updates

Updates with uncommited changes will always only have one ancestor - the parent
revision. Updates between existing revision should (and will) always give the
same result no matter which ancestor is used. The warning is thus only relevant
when doing a "real" merge.

--HG--
branch : stable
changectx: ancestor should only prefer merge.preferancestor if it is a revision

The value '*' currently designates that bid merge should be used. The best
way to test bid merge is to set preferancestor=* in the configuration file ...
but then it would abort with unknown revision '*' when other code paths ended
up in changectx.ancestor .

Instead, just skip and ignore the value '*' when looking for a preferred
ancestor.

--HG--
branch : stable
tests: improve test coverage for discovery and actual parameters for pulling

--HG--
branch : stable
incoming: don't request heads that already are common

Pull would send a getbundle command where common heads were sent both as common
and head, even though there is no reason to request a common head.
The request was thus twice as big as necessary and more likely to hit HTTP
header size limits.

Instead, don't request heads that already are common.

This is fixed in bundlerepo.getremotechanges . It could perhaps also have been
fixed in discovery.findcommonincoming but that would have a bigger impact.

--HG--
branch : stable
annotate: rewrite long short-circuit statement by if-elif-else
annotate: inline definition of decorate() functions
largefiles: put whole "hgupdaterepo" process into the same "wlock" scope

Before this patch, there are two distinct "wlock" scopes below in
"hgupdaterepo":

  1. "merge.update" via original "hg.updaterepo" function
  2. "updatelfiles" specific "wlock" scope (to synchronize largefile
     dirstate)

In addition to them, "dirstate.walk" is executed between these "wlock"
scopes.

But these should be executed in the same "wlock" scope for
consistency, because many (indirect) users of "hg.updaterepo" don't
get "wlock" explicitly before invocation of it.

"hg.clean" is invoked without "wlock" from:

  - mqrepo.restore in mq
  - bisect in commands
  - update in commands

"hg.update" is invoked without "wlock" from:

  - clone in mq
  - pullrebase in rebase
  - postincoming in commands (used in "hg pull -u", "hg unbundle")
  - update in commands

This patch puts almost all original "hgupdaterepo" implementation into
"_hgupdaterepo" to reduce changes.
largefiles: put whole "hgmerge" process into the same "wlock" scope

Before this patch, there are two distinct "wlock" scopes below in
"hgmerge":

  1. "merge.update" via original "hg.merge" function
  2. "updatelfiles" specific "wlock" scope (to synchronize largefile
     dirstate)

But these should be executed in the same "wlock" scope for
consistency, because users of "hg.merge" don't get "wlock" explicitly
before invocation of it.

  - merge in commands

This patch puts almost all of the original "hgmerge" implementation into
"_hgmerge" to reduce changes.
largefiles: add test for large/normal conflict at linear merging

Before this patch, there is no explicit test for it: test-issue3084.t
seems to test such conflict only at branch merging.

This patch uses "[debug] dirstate.delaywrite" feature for the tests
expecting "M" status of largefiles, to confirm certainly whether files
are marked unexpectedly as "clean".