log: fix behavior with empty repositories (issue3497)

Make output in this special case consistent with general case one.
annotate: reuse already calculated annotation

Before this patch, annotation is re-calculated even if it is already
calculated. This may cause unexpected annotation, because already
cleared "pcache" ("pcache[f] = []") prevents from scanning ancestors.

This patch reuses already calculated annotation if it is available.

In fact, "reusable" situation should be seen only on legacy
repositories in which a filelog include the merging between the
revision and its ancestor, because:

  - tree is scanned in depth-first

    without such merging, annotation result should be released soon

  - recent Mercurial doesn't allow such merging

    changelog and manifest can include such merging someway, but
    filelogs can't, because "localrepository._filecommit()" converts
    such merging request to linear history.
annotate: increase refcount of each revisions correctly (issue3841)

Before this patch, refcount (managed in "needed") of parents of each
revisions in "visit" is increased, only when parent is not annotated
yet (examined by "p not in hist").

But this causes less refcount of the revision like "A" in the tree
below ("A" is assumed as the second parent of "C"):

    A --- B --- C
      \       /
       \-----/

Steps of annotation for "C" in this case are shown below:

  1. for "C"
    1.1 increase refcount of "B"
    1.2 increase refcount of "A" (=> 1)
    1.3 defer annotation for "C"

  2. for "A"
    2.1 annotate for "A" (=> put result into "hist[A]")
    2.2 clear "pcache[A]" ("pcache[A] = []")

  3. for "B"
    3.1 not increase refcount of "A", because "A not in hist" is False
    3.2 annotate for "B"
    3.3 decrease refcount of "A" (=> 0)
    3.4 delete "hist[A]", even though "A" is still needed by "C"
    3.5 clear "pcache[B]"

  4. for "C", again
    4.1 not increase refcount of "B", because "B not in hist" is False
    4.2 increase refcount of "A" (=> 1)
    4.3 defer annotation for "C"

  5. for "A", again
    5.1 annotate for "A" (=> put result into "hist[A]", again)
    5.2 clear "pcache[A]"

  6. for "C", once again
    6.1 not increase refcount of "B", because "B not in hist" is False
    6.2 not increase refcount of "A", because "A not in hist" is False
    6.3 annotate for "C"
    6.4 decrease refcount of "A", and delete "hist[A]"
    6.5 decrease refcount of "B", and delete "hist[B]"
    6.6 clear "pcache[C]"

At step (5.1), annotation for "A" mis-recognizes that all lines are
created at "A", because "pcache[A]" already cleared at step (2.2)
prevents from scanning ancestors of "A".

So, annotation for "C" or its descendants loses information about "A"
or its ancestors.

The root cause of this problem is that refcount of "A" is decreased at
step (3.3), even though it isn't increased at step (3.1).

To increase refcount correctly, this patch increases refcount of each
parents of each revisions:

  - regardless of "p not in hist" or not, and
  - only once for each revisions in "visit" (by "not pcached")

In fact, this problem should occur only on legacy repositories in
which a filelog includes the merging between the revision and its
ancestor (as the second parent), because:

  - tree is scanned in depth-first

    without such merging, revisions in "visit" refer different
    revisions as parent each other

  - recent Mercurial doesn't allow such merging

    changelog and manifest can include such merging someway, but
    filelogs can't, because "localrepository._filecommit()" converts
    such merging request to linear history.

This patch tests merging cases below: these cases are from filelog of
"mercurial/commands.py" in the repository of Mercurial itself.

  - both parents are same

        10 --- 11 --- 12
                  \_/

        filelogrev: changesetid:
          10          00ea3613f82c
          11          fc4a6e5b5812
          12          4f802588cdfb

  - the second parent is also ancestor of the first one

        37 --- 38 --- 39 --- 40
                  \________/

        filelogrev: changesetid:
          37          f8d56da6ac8f
          38          38919e1c254d
          39          d3400605d246
          40          f06a4a3b86a7
summary: make "outgoing" information sensitive to branch in URL (issue3829)

Before this patch, "outgoing" information of "hg summary --remote" is
not sensitive to the branch specified in the URL of the destination
repository, even though "hg push"/"hg outgoing" are so:

Invocation of "discovery.findcommonoutgoing()" without "onlyheads"
argument treats revisions on branches other than the one specified in
the URL as outgoing ones unexpectedly.

This patch looks head revisions, which are already detected by
"hg.addbranchrevs()" from URL, up against local repository, and
invokes "discovery.findcommonoutgoing()" with list of them as
"onlyheads" to limit calculation of outgoing revisions.
histedit: make "hg histedit" sensitive to branch in URL

Before this patch, "hg histedit" are not sensitive to the branch
specified in the URL of the destination repository, even though "hg
push"/"hg outgoing" are so:

Invocation of "discovery.findcommonoutgoing()" without "onlyheads"
argument treats revisions on branches other than the one specified in
the URL as outgoing ones unexpectedly.

This patch specifies list of head revisions, which are already
detected by "hg.addbranchrevs()" from URL and looked up against local
repository, as "onlyheads" to "discovery.findcommonoutgoing()" to
limit calculation of outgoing revisions.
summary: make "incoming" information sensitive to branch in URL (issue3830)

Before this patch, "incoming" information of "hg summary --remote" is
not sensitive to the branch specified in the URL of the destination
repository, even though "hg pull"/"hg incoming" are so.

Invocation of "discovery.findcommonincoming()" without "heads"
argument treats revisions on branches other than the one specified in
the URL as incoming ones unexpectedly.

This patch looks head revisions, which are already detected by
"hg.addbranchrevs()" from URL, up against "other" repository, and
invokes "discovery.findcommonincoming()" with list of them as "heads"
to limit calculation of incoming revisions.
summary: clear "commonincoming" also if branches are different

Before this patch, "commonincoming" calculated by
"discovery.findcommonincoming()" is cleared, only if "default" URL
without branch part (tail "#branch" of URL) differs from
"default-push" URL without branch part.

But common revisions in "commonincoming" calculated for a branch
doesn't include ones for another branch, even if URLs without branch
part are same. The result of "discovery.findcommonoutgoing()"
invocation with such "commonincoming" becomes incorrect in some cases.

This patch clears "commonincoming", also if branch part of "default"
differs from one of "default-push".

To avoid redundant looking up:

  - "ui.expandpath('default')" and "ui.expandpath('default-push',
    'default')" are not compared directly, even though they contain
    branch information, because they are not yet normalized by
    "hg.parseurl()": tail "/" of path, for example

  - "commonincoming" is not cleared, if branch isn't specified in
    "default" URL, because such "commonincoming" contains common
    revisions for all branches

This patch also tests "different path, same branch" pattern to check
careless degrading around comparison between source and destination.