contrib/vagrant: use Vagrant for running tests on virtual machine

  $ cd contrib/vagrant
  $ vagrant up
  $ vagrant ssh -c ./run-tests.sh

Repository is shared at /hgshared in guest machine.
log: make --patch --follow work inside a subdirectory

Previously, the 'patch' code for hg log --patch --follow would try to resolve
patterns relative to the repository root rather than the current working
directory. Fix that by using match.files instead of pats, as done elsewhere
nearby.

--HG--
branch : stable
mergetools: add --nofork option to gvimdiff.diffargs for extdiff

Without --nofork, temporary files are removed immediately before gvimdiff
starts.  "-d -g -O" are put just for consistency with gvimdiff.args.
merge with stable
log: use an exact matcher for --patch --follow

The arguments to log --patch --follow are expected to be exact paths.

This will be used to make manifest filtering for these cases more efficient in
upcoming patches.

--HG--
extra : rebase_source : bbdac809981b167524078e8128e4cf9cc910b975
manifestdict: add a new method to intersect with a set of files

This is meant to be used when the set of files is known in advance, e.g. with a
match object with no patterns.

--HG--
extra : rebase_source : 3e95a92417a55c7e8fddf18066df2f08f67313b5
context: generate filtered manifest efficiently for exact matchers

When the matcher is exact, there's no reason to iterate over the entire
manifest. It's much more efficient to iterate over the list of files instead.

For a repository with approximately 300,000 files, this speeds up
hg log -l10 --patch --follow for a frequently modified file from 16.5 seconds
to 10.5 seconds.

--HG--
extra : rebase_source : e456afa62c2d89201f79bf4e841136640d58de6c
largefiles: add tests for summary/outgoing improved in subsequent patches

This patch adds tests for summary/outgoing improved in subsequent
patches, to reduce amount of diffs in each patches.

This patch adds new revisions below:

  - revision #2 adds new largefiles, but they contain as same data as
    one already existing

    this causes that multiple standins refer the same data entity

  - revision #3, #4 and #5 change the already existing largefile

    this causes that multiple data entities are outgoing for the standin.
    #5 can be used to check de-duplication of "(hash, filename)" pair.

--HG--
extra : rebase_source : 77ac360b47a67988b40d6f7bea10b65ff02cfcb0
largefiles: show also how many data entities are outgoing at "hg summary"

Before this patch, "hg summary --large" shows how many largefiles are
changed or added in outgoing revisions only in the point of the view
of filenames.

For example, according to the number of outgoing largefiles shown in
"hg summary" output, users should expect that the former below costs
much more to upload outgoing largefiles than the latter.

  - outgoing revisions add a hundred largefiles, but all of them refer
    the same data entity

    in this case, only one data entity is outgoing, even though "hg
    summary" says that a hundred largefiles are outgoing.

  - a hundred outgoing revisions change only one largefile with
    distinct data

    in this case, a hundred data entities are outgoing, even though
    "hg summary" says that only one largefile is outgoing.

But the latter costs much more than the former, in fact.

This patch shows also how many data entities are outgoing at "hg
summary" by counting number of unique hash values for outgoing
largefiles.

This patch introduces "_getoutgoings" to centralize the logic
(de-duplication, too) into it for convenience of subsequent patches,
even though it is not required in "hg summary" case.

--HG--
extra : rebase_source : 3fb82d6d1586af553c1ac6c78aa399cd87ca88f5
largefiles: show also how many data entities are outgoing at "hg outgoing"

Before this patch, "hg outgoing --large" shows which largefiles are
changed or added in outgoing revisions only in the point of the view
of filenames.

For example, according to the list of outgoing largefiles shown in "hg
outgoing" output, users should expect that the former below costs much
more to upload outgoing largefiles than the latter.

  - outgoing revisions add a hundred largefiles, but all of them refer
    the same data entity

    in this case, only one data entity is outgoing, even though "hg
    summary" says that a hundred largefiles are outgoing.

  - a hundred outgoing revisions change only one largefile with
    distinct data

    in this case, a hundred data entities are outgoing, even though
    "hg summary" says that only one largefile is outgoing.

But the latter costs much more than the former, in fact.

This patch shows also how many data entities are outgoing at "hg
outgoing" by counting number of unique hash values for outgoing
largefiles.

When "--debug" is specified, this patch also shows what entities (in
hash) are outgoing for each largefiles listed up, for debug purpose.

In "ui.debugflag" route, "addfunc()" can append given "lfhash" to the
list "toupload[fn]" always without duplication check, because
de-duplication is already done in "_getoutgoings()".

--HG--
extra : rebase_source : 01668d05e3f112cbd3dd73a58aeeaa86578bd663
largefiles: confirm existence of outgoing largefile entities in remote store

Before this patch, "hg summary" and "hg outgoing" show and count up
all largefiles changed/added in outgoing revisions, even though some
of them are already uploaded into remote store.

This patch confirms existence of outgoing largefile entities in remote
store, to show and count up only really outgoing largefile entities at
"hg summary" and "hg outgoing".

--HG--
extra : rebase_source : ea5b13a46049e307a6880c94fe25a4dc63b8fffb
subrepo: ensure "lock.release()" execution at the end of "storeclean()"

Before this patch, "lock.release()" for "self._repo" in "storeclean()"
of "hgsubrepo" may not be executed, if unexpected exception is raised,
because it isn't executed in "finally" clause.

This patch ensures "lock.release()" execution at the end of
"storeclean()" by moving it into "finally" clause.

This patch chooses moving almost all lines in "storeclean()" into
"_storeclean()" instead of indenting them for "try/finally" clauses,
to keep diff simple for review-ability.

--HG--
extra : rebase_source : 1e3d6140eb9efac59619413daa922b5cb4cbc567
subrepo: ensure "lock.release()" execution at the end of "_cachestorehash()"

Before this patch, "lock.release()" for "self._repo" in
"_cachestorehash()" of "hgsubrepo" may not be executed, if unexpected
exception is raised, because it isn't executed in "finally" clause.

This patch ensures "lock.release()" execution at the end of
"_cachestorehash()" by moving it into "finally" clause.

--HG--
extra : rebase_source : fb99c9c02dff7e9e0c4acba8991185b746aa42b1
subrepo: ensure "close()" execution at the end of "_calcfilehash()"

Before this patch, "close()" for the file object opened in
"_calcfilehash()" may not be executed, if unexpected exception is
raised, because it isn't executed in "finally" clause.

This patch ensures "close()" execution at the end of "_calcfilehash()"
by moving it into "finally" clause.

--HG--
extra : rebase_source : e1c76d66829d1341a1688708452c2a5947b5c988
subrepo: ensure "close()" execution at the end of "_readstorehashcache()"

Before this patch, "close()" for the file object opened in
"_readstorehashcache()" may not be executed, if unexpected exception
is raised, because it isn't executed in "finally" clause.

This patch ensures "close()" execution at the end of
"_readstorehashcache()" by moving it into "finally" clause.

--HG--
extra : rebase_source : b5a853b23537d74f6ec04cfc376ccfb7bf959058
subrepo: ensure "close()" execution at the end of "_cachestorehash()"

Before this patch, "close()" for the file object opened in
"_cachestorehash()" may not be executed, if unexpected exception is
raised, because it isn't executed in "finally" clause.

This patch ensures "close()" execution at the end of
"_cachestorehash()" by moving it into "finally" clause.

--HG--
extra : rebase_source : b48d37f0aa944cb8eeb3b9520c72411b3eaabe0d
subrepo: add test whether "[paths]" is configured correctly at subrepo creation

This test is added for changes in the subsequent patch.

This test doesn't use "(glob)" for expected output, because "[paths]"
is configured at subrepo creation by "_abssource()" using
"posixpath.join()" to join path components.

--HG--
extra : rebase_source : 3a33014dd4969266d202263b7ab021ab9bc34c4c
subrepo: ensure "close()" execution at the end of "_initrepo()"

Before this patch, "close()" for the file object opened in
"_initrepo()" may not be executed, if unexpected exception is raised,
because it isn't executed in "finally" clause.

This patch ensures "close()" execution at the end of "_initrepo()" by
moving it into "finally" clause.

This patch puts configuration lines into "lines" array and write them
out at once, to narrow the scope of "try"/"finally" for review-ability.

This patch doesn't use "vfs.write()", because:

  - current "vfs.write()" implementation doesn't take "mode" argument
    to open file in "text" mode

  - writing hgrc file out in binary mode may break backward compatibility

--HG--
extra : rebase_source : 2f5c898da803d7e4c24950aa3f12d903ab9cd309