convert: use None value for missing files instead of overloading IOError

The internal API used IOError to indicate that a file should be marked as
removed.

There is some correlation between IOError (especially with ENOENT) and files
that should be removed, but using IOErrors to represent file removal internally
required some hacks.

Instead, use the value None to indicate that the file not is present.

Before, spurious IO errors could cause commits that silently removed files.
They will now be reported like all other IO errors so the root cause can be
fixed.
convert: remove incorrect and unused handling of removed svn directories

Since it was introduced in f0c58fd4b798, tidy_dirs has been comparing
the result of os.listdir with a string - which never can be true.
Convert apparently works anyway and there is no test coverage of it.

It also seems like it could make a bigger difference on older svn versions but
is less relevant with more recent versions.

Instead of trying to fix the code, we take the low risk option and remove it.
convert: refactor subversion getchanges and caching
convert: refactor hg getchanges and caching
convert: introduce --full for converting all files

Convert will normally only process files that were changed in a source
revision, apply the filemap, and record it has a change in the target
repository. (If it ends up not really changing anything, nothing changes.)

That means that _if_ the filemap is changed before continuing an incremental
convert, the change will only kick in when the files it affects are modified in
a source revision and thus processed.

With --full, convert will make a full conversion every time and process
all files in the source repo and remove target repo files that shouldn't be
there. Filemap changes will thus kick in on the first converted revision, no
matter what is changed.

This flag should in most cases not make any difference but will make convert
significantly slower.

Other names has been considered for this feature, such as "resync", "sync",
"checkunmodified", "all" or "allfiles", but I found that they were less obvious
and required more explanation than "full" and were harder to describe
consistently.
templater: enable alias predicates to be used in "revset()" function

Before this patch, predicates defined in "[revsetalias]" can't be used
in the query specified to template function "revset()", because:

  - "revset()" uses "localrepository.revs()" to get query result, but
  - "localrepository.revs()" passes "None" as "ui" to "revset.match()", then
  - "revset.match()" can't recognize any alias predicates

To enable alias predicates to be used in "revset()" function, this
patch invokes "revset.match()" directly with "repo.ui".

This patch doesn't make "localrepository.revs()" pass "self.ui" to
"revset.match()", because this may be intentional implementation to
prevent alias predicates from shadowing built-in ones and breaking
functions internally using "localrepository.revs()".

Even if it isn't intentional one, the check for shadowing should be
implemented (maybe on default branch) before fixing it for safety.
log: use correct phase info for parent field (issue4347)

Previously, there was a copy / paste error with using the current changeset's
phase information. We now look up the parent context explicitly.

The line was too long so it is stored into a variable first.

--HG--
branch : stable
extra : rebase_source : da9880e60ecbad3fc97e2a3537c09599a3adc28d
graft: fix collision detection with origin revisions that are missing

When grafting something with a matching origin, it would normally be skipped:
  skipping already grafted revision 123 (23 also has origin 12)

But after stripping a graft origin, graft could fail with a reference to the
origin that no longer exists:
  abort: unknown revision '5c095ad7e90f871700f02dd1fa5012cb4498a2d4'!

Instead, detect that the origin is unknown and skip it anyway, like:
  skipping already grafted revision 8 (2 also has unknown origin 5c095ad7e90f871700f02dd1fa5012cb4498a2d4)

--HG--
branch : stable
import: show the warning message for failure of merging

Before this patch, no message is shown for failure of merging at "hg
import".

In such case, merging patch is imported as a normal revision silently,
and it may confuse users.

For simplicity, this patch recommends just using "--exact", even
though importing the merging patch itself is possible without it if:

  - the hash of the 1st parent in the patch is equal to one of the
    patch imported just before (or the parent of the working
    directory, for the 1st patch of the series), and

  - the hash of the 2nd parent in the patch is known in the local
    repository

--HG--
branch : stable
merge with stable