merge default into stable for 3.1 code freeze

--HG--
branch : stable
Added tag 3.1-rc for changeset 6c36dc6cd61a

--HG--
branch : stable
Added signature for changeset 6c36dc6cd61a

--HG--
branch : stable
commands: fix typo in import documentation

--HG--
branch : stable
i18n-pt_BR: synchronized with 6c36dc6cd61a

--HG--
branch : stable
tests: cat error messages are different on Solaris

--HG--
branch : stable
dirstate: delay writing out to ensure timestamp of each entries explicitly

Even though "dirstate.write()" is invoked explicitly after "normal"
invocations, timestamp field of entries may be still "unset" in the
"dirstate" file itself , because "pack_dirstate" drops it when it is
equal to the timestamp of "dirstate" file itself.

This can avoid overlooking modification of files, which are updated at
same time in the second. But on the other hand, this may hide timing
critical problems.

For example, incorrect "normal"-ing (or lack of "normallookup"-ing on
the already "normal"-ed entry) is visible only when:

  - the target file is modified in the working directory at T1, and
  - "dirstate" file is written out at T2 (!= T1)

Otherwise, T1 is dropped by "pack_dirstate" in "dirstate.write()"
invocation, and "unset" is stored into "dirstate" file.

It often fails to reproduce problems from incorrect "normal"-ing by
Mercurial testset, because automated actions in the small repository
almost always causes that T1 and T2 are same.

This patch adds the debug feature to delay writing out to ensure
timestamp of each entries explicitly.

This feature is used to make timing critical "dirstate" problems
reproducable in subsequent patches.

--HG--
branch : stable
largefiles: use "normallookup", if "mtime" of standin is unset

Before this patch, largefiles gotten from "other" revision (without
conflict) at "hg merge" become "clean" unexpectedly in steps below:

    1. "merge.update()" is invoked
      1-1 standinfile SF is updated in the working directory
      1-2 "dirstate" entry for SF is "normallookup"-ed

    2. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
      2-1 largefile LF (for SF) is updated in the working directory
      2-2 "dirstate" returns "n" for SF (by 1-2)
      2-3 "lfdirstate" entry for LF is "normal"-ed
      2-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
          timestamp of LF is stored into "lfdirstate" file
          (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)

Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 2-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 2-3 and 2-4) as "clean".

When timestamp is not set (= negative value) for standinfile in
"dirstate", largefile should be "normallookup"-ed regardless of
rebasing or not, because "n" state in "dirstate" doesn't ensure
"clean"-ness of a standinfile at that time.

This patch uses "normallookup" instead of "normal", if "mtime" of
standin is unset

This is a temporary way to fix with less changes. For fundamental
resolution of this kind of problems in the future, "lfdirstate" should
be updated with "dirstate" simultaneously while "merge.update"
execution: maybe by hooking "recordupdates"

It is also why this patch (temporarily) uses internal field "_map" of
"dirstate" directly.

This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 2-4)

This patch newly adds "test-largefiles-update.t", to avoid increasing
cost to run other tests for largefiles by subsequent patches
(especially, "[debug] dirstate.delaywrite" causes so).

--HG--
branch : stable
largefiles: invoke "normallookup" on "lfdirstate" for merged files

Before this patch, largefiles gotten from "other" revision (with
conflict) at "hg merge" become "clean" unexpectedly in steps below:

    1. "repo.status()" is invoked (for status check before merging)
      1-1 "dirstate" entry for standinfile SF is "normal"-ed
      1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed

    2. "merge.update()" is invoked
      2-1 SF is updated in the working directory
          (ASSUMPTION: user choice "other" at conflict)
      2-2 "dirstate" entry for SF is "merge"-ed

    3. "lfcommands.updatelfiles()" is invoked (by "overrides.hgmerge()")
      3-1 largefile LF (for SF) is updated in the working directory
      3-2 "dirstate" returns "m" for SF (by 2-2)
      3-3 "lfdirstate" entry for LF is left as it is
      3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
          timestamp of LF is stored into "lfdirstate" file (by 1-2)
          (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)

Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 1-2 and 3-4) as "clean".

When state of standinfile in "dirstate" is "m", largefile should be
"normallookup"-ed.

This patch invokes "normallookup" on "lfdirstate" for merged files.

This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate". (for ASSUMPTION at 3-4)

--HG--
branch : stable
largefiles: use "normallookup" on "lfdirstate" while reverting

Before this patch, largefiles gotten from revisions other than the
parent of the working directory at "hg revert" become "clean"
unexpectedly in steps below:

    1. "repo.status()" is invoked (for status check before reverting)
      1-1 "dirstate" entry for standinfile SF is "normal"-ed
     (1-2 "lfdirstate" entry of largefile LF (for SF) is "normal"-ed)

    2. "cmdutil.revert()" is invoked
      2-1 standinfile SF is updated in the working directory
      2-2 "dirstate" entry for SF is NOT updated

    3. "lfcommands.updatelfiles()" is invoked (by "overrides.overriderevert()")
      3-1 largefile LF (for SF) is updated in the working directory
      3-2 "dirstate" returns "n" and valid timestamp for SF (by 1-1 and 2-2)
      3-3 "lfdirstate" entry for LF is "normal"-ed
      3-4 "lfdirstate" is written into ".hg/largefiles/dirstate", and
          timestamp of LF is stored into "lfdirstate" file (by 3-3)
          (ASSUMPTION: timestamp of LF differs from one of "lfdirstate" file)

Then, "hs status" treats LF as "clean", even though LF is updated by
"other" revision (by 3-1), because "lfilesrepo.status()" always treats
"normal"-ed files (by 3-3 and 3-4) as "clean".

When largefiles are reverted, they should be "normallookup"-ed
forcibly.

This patch uses "normallookup" on "lfdirstate" while reverting, by
passing "True" to newly added argument "normallookup".

Forcible "normallookup"-ing is not so expensive, because list of
target largefiles is explicitly specified in this case.

This patch uses "[debug] dirstate.delaywrite" feature in the test, to
ensure that timestamp of the largefile gotten from "other" revision is
stored into ".hg/largefiles/dirstate" (for ASSUMPTION at 3-4)

--HG--
branch : stable
merge with i18n

--HG--
branch : stable
version: don't traceback if no extensions to list (issue4312)

--HG--
branch : stable
extra : amend_source : acea7f08ff16ddea44b38c5ec7cc0c87fb563978
memctx: substate needs to be {} instead of None

Setting substate to None was an oversight in 7cfd94ec5d30 and this patch
corrects it by setting substate to an empty dictionary which matches what
subrepo code expects.

--HG--
branch : stable
revset: optimize baseset.__sub__ (issue4313)

dd716807fd23 regressed performance of baseset.__sub__ by introducing
a lazyset. This patch restores that lost performance by eagerly
evaluating baseset.__sub__ if the other set is a baseset.

revsetbenchmark.py results impacted by this change:

revset #6: roots(0::tip)
0) wall 2.923473 comb 2.920000 user 2.920000 sys 0.000000 (best of 4)
1) wall 0.077614 comb 0.080000 user 0.080000 sys 0.000000 (best of 100)

revset #23: roots((0:tip)::)
0) wall 2.875178 comb 2.880000 user 2.880000 sys 0.000000 (best of 4)
1) wall 0.154519 comb 0.150000 user 0.150000 sys 0.000000 (best of 61)

On the author's machine, this slowdown manifested during evaluation of
'roots(%ln::)' in phases.retractboundary after unbundling the Firefox
repository. Using `time hg unbundle firefox.hg` as a benchmark:

Before: 8:00
After:  4:28
Delta: -3:32

For reference, the subset and cs baseset instances impacted by this
change were of lengths 193634 and 193627, respectively.

Explicit test coverage of roots(%ln::), while similar to the existing
roots(0::tip) benchmark, has been added.

--HG--
branch : stable
resolve: report no argument warning using a hint

With this change resolve and revert produce consistent output when run with no
arguments:

$ hg resolve
abort: no files or directories specified
(use --all to remerge all files)

$ hg revert
abort: no files or directories specified
(use --all to revert all files)

--HG--
branch : stable
bundle2: only use callable return as reply handler

When a bundle2 parts generator returns a non callable value, it should not be
used as a reply handler. The changegroup part generator is already having this
case of behavior when there is no changegroup to push. This changeset prevent a
crash for user of the experimentable bundle2 feature.

--HG--
branch : stable
test-status: add test for removed-and-untracked state (BC)

In Mercurial 3.0, "hg status" can list the same file twice if it was removed
but still exists in working directory, i.e. removed by "hg forget":

  $ hg status --rev 0 removed
  R removed
  ? removed

But since 65cdc6bab91e, untracked state, "?", is no longer displayed in this
example.

I think the new behavior is correct since a file should have single state, but
if it is a bug, this patch should be dropped.

--HG--
branch : stable
help: use --template to specify existing style

--style is deprecated since 3a35ba2681ec and 870d60294b04.

--HG--
branch : stable
extra : rebase_source : 8fe17fe29b5c4cccc6df6eb33e357537f673321e
templates: re-add template listing support

We used to have --style nosuch to list templates, but --style is now
merged with --template/-T where random strings are acceptable
templates. So we reserve 'list' to allow listing templates.

--HG--
branch : stable
extra : rebase_source : 8696e5260220644304a2d9d9adb63bf3ce4a543d
help: drop reference to glog in templates topic

--HG--
branch : stable
extra : rebase_source : 443ea96d5ec7e615707fa6138f5fb4ce9327e64c