pull: fix post-pull common computation

Before that changes, pulled revision that happend to be already known locally
(so, not actually added) was not taken into account when computing the new
common set between local and remote.

It appears that we already know the heads of the pulled set. It is in the
`rheads` variable, so we are just using it and everything is works fine.

We are dropping the, now useless, computation of `added` set in the process.
push: more robust check for bundle fast path

When all changesets in the local repo are either being pushed or remotly known,
we can take a fast path when bundling changeset because we are certain all local
deltas are computed againts base known remotely.

So we have a check to detect this situation, when we did a bare push and nothing
was excluded.

In a coming refactoring, the discovery will run on filtered view and the content
of `outgoing.excluded` will just include unserved (secret) changeset not filtered by the
repoview used to call push (usually "visible"). So we need to check if there is
both no excluded changeset and nothing filtered by the current repoview.
pull: run findcommon incoming on unfiltered repo

The discovery is not yet ready for filtered repo. Pull was using filtered for
its discovery which is wrong. It worked by dumb luck because discovery mainly
use funtion that does not respect the filtering.

Trying to makes discovery work on filtered repo revealed this bug.
discovery: make revlogdag work on filtered repo

The revlogdag class is a core part of discovery. We need its initialisation to
exclude revision filtered out.
discovery: enforce filtering into revlogbaseddag._internalizeall

One more step toward discovery running on filtered repo.
discovery: stop using nodemap for membership testing

Nodemap is not aware of filtering so we need to ask the changelog itself if a
node is known. This is probably a bit slower but such check does not dominated
discovery time. This is necessary if we want to run discovery on filtered repo.
i18n-de: rename noun "entfernt" to "Gegenseite"

The German translation for "remote" as "entfernt" can be misleading
in situations where remote is used as a noun. "entfernt" is not a
noun and can also mean "removed". To clarify this we rename "remote"
to "Gegenseite" when used as a noun.
localrepo: drop unused variable
doc: bump copyright year
merge with stable
tests: test-convert-cvs-synthetic.t requires cvs 1.12

9589227657bc introduced hghave cvs112 10 months ago. Let's assume it has
stabilized so much that we can start using it now.
commands.bookmarks: separate out 'no bookmarks set' status messages

Upcoming patches will acquire the wlock for write operations, such as make
inactive, but not read-only ones, such as list bookmarks. Separate out the
status messages so that the code paths can be separated.
commands.bookmarks: hold wlock for write operations

Any invocations of bookmarks other than a plain 'hg bookmarks' will likely
cause a write to the bookmark store. These should be guarded by the wlock.

The repo._bookmarks read should be similarly guarded by the wlock if we're
going to be subsequently writing to it.
commands.bookmarks: pass cur in explicitly to checkconflict

cur will be moved inside the wlock in a future patch, so we need to pass it
into checkconflict explicitly.
commands.bookmarks: move cur initialization to inside wlock

This is more correct because we now fetch '.' while nothing else can interfere
with it.
commands.bookmarks: move hexfn to inside list block

This isn't used outside this block, nor is it expected to be.
context: drop caching 'copies' method

The 'copies' method has no test coverage and calls copies.pathcopies with an
incorrect number of parameters and is thus (fortunately) not used. Kill it.
bisect: --command without --noupdate should flag the parent rev it tested

14913fcb30c6 not only introduced the 'bisect(current)' revset predicate, it
also changed how the 'current' revision is used in combination with --command.
The new behaviour might be ok for --noupdate where the working directory and
its revision shouldn't be used, but it also did that when --command is used to
run a command on the currently checked out revision then it could register the
test result on the wrong revision.

An example:

Before, bisect with --command could use the wrong revision when recording the
test result:

  $ hg up -qr 0
  $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
  changeset 31:58c80a7c8a40: bad
  abort: inconsistent state, 31:58c80a7c8a40 is good and bad

Now it works as before and as expected and uses the working directory revision
for the --command result:

  $ hg up -qr 0
  $ hg bisect --command "python \"$TESTTMP/script.py\" and some parameters"
  changeset 0:b99c7b9c8e11: bad
  ...
check-code: do not skip entire file, skip only one match instead

Skipping of the entire file has been introduced in bc3b48b0f5c8.
check-code: always report when a file is skipped by "no-check-code"

Skipping an entire file generally from checking is an important event, so
report it always.
Do not tell the check name because skipping does not depend on it. Directly
skip the entire file instead of checking more patterns and skip again.

The pragma no-check-code was introduced by accident in the past. (Fixed in
e033a7d444ac and ee07f9d142c9.) This now is prevented because the files
to skip have to be listed in the test output of test-check-code-hg.t.