update: remove unnecessary check for unknown files with --check

As far as I and the test suite can tell, the checks in manifestmerge()
already report the errors (whether or not --check is given), so we
don't need to call merge.checkunknown(). Since this is the last call
to the method, also remove the method.

--HG--
extra : histedit_source : caac8835437c0927eaee523afcb783b5433112b2
run-tests: don't warn on unnecessary globs mandated by check-code.py

When test output is processed, if os.altsep is defined (i.e. on Windows),
TTest.globmatch() will cause a warning later on if a line has a glob that isn't
necessary.  Unfortunately, the regex checking in check-code.py doesn't have this
context.  Therefore we ended up with cases where the test would get flagged with
a warning only on Windows because a glob was present, because check-code.py
would warn if it wasn't.  For example, from test-subrepo.t:

    $ hg -R issue1852a push `pwd`/issue1852c
    pushing to $TESTTMP/issue1852c (glob)

The glob isn't necessary here because the slash is shown as it was provided.
However, check-code mandates one to handle the case where the default path has
backslashes in it.

Break the cycle by checking against a subset of the check-code rules before
flagging the test with a warning, and ignore the superfluous glob if it matches
a rule.  This change fixes warnings in test-largefiles-update.t, test-subrepo.t,
test-tag.t, and test-rename-dir-merge.t on Windows.

I really hate that the rules are copy/pasted here (minus the leading two spaces)
because it would be nice to only update the rules once, in a single place.  But
I'm not sure how else to do it.  I'm open to suggestions.  Splitting some of the
rules out of check-code.py seems wrong, but so does moving check-code.py out of
contrib, given that other checking scripts live there.

There are other glob patterns that could be copied over, but this is enough to
make the current tests run on Windows.

--HG--
extra : histedit_source : aeea93715559c98af479aa6c3116b1efa12ab16b
tests: handle differences between missing file error strings on Windows and Unix

--HG--
extra : histedit_source : b66424721b755eeec728c157b841d232e9da90fb
transaction: accept a 'location' argument for registertmp

This will allow generation of temporary files outside of store. This will be
useful for bookmarks.

--HG--
extra : histedit_source : b8a357b8f93d9eb9179b931e3a18d4b5832b79e4
transaction: fix some docstring grammar
transaction: allow generating files with a suffix

This will allow us to generate temporary pending files. Files
generated with a suffix are assumed temporary and will be cleaned up
at the end of the transaction.
transaction: have _generatefile return a boolean

The function returns True if any files were generated. This will be
used to know if any pending files have been written.
transaction: write pending generated files

Such file are generated with a .pending prefix. It is up to the reader to
implement the necessary logic for reading pending files.

We add a test to ensure pending files are properly cleaned-up in both success and
error cases.
test-bundle2: check visible data in pre/post-transaction hooks

We are about to make bookmarks and phases available for hooks.
Therefore we need a witness for this new availability. We introduce
the new hooks in a distinct changeset to reduce the noise in the ones
with actual changes.
bookmark: read pending data when appropriate

If we are called by a hook and pending data exists, read it.
phases: read pending data when appropriate

If we are called by a hook and pending data exists, read those.
merge: remove confusing comment about --force

manifestmerge() has a piece of code that's roughly:

  if not force and different:
      abort
  else:
      # if different: old untracked f may be overwritten and lost
      ...

The comment only talks about what happens when 'different' is true,
and in combination with the if-block above, that must mean that it is
only about what happens when 'force and different'. It seems quite
fine that files are overwritten when 'force' is true, so let's remove
the comment. As it stands, it can easily be interpreted as a TODO
(which is how I interpreted it at first).