repoview: extract hideable revision computation in a dedicated function

This will help extensions to plug into the hidden mechanism.
Merge with stable.
test-keyword: improve grammar and spelling in branchcache note

See: da9e544c69d6
subrepo: fix python2.4 compatibility after 9aa6bee6e9f9

super(SubrepoAbort, self).__init__(*args, **kw) raises
  TypeError: super() argument 1 must be type, not classobj
subrepo: make 'in subrepo' string easier to find by external tools

This patch is meant to make it easier for tools that wrap the mercurial
output (such as TortoiseHg) to find the "in subrepo MYSUBREPO" string that
(since 9e3910db4e78) is appended after subrepo error messages, particularly when
the mercurial output is translated to a non-English language.

The message remains the same but the '%s' that was used to prepend the original
error message in front of the 'in subrepo' string has been moved out of the
translatable string.

As an example of the usefulness of making it easy to look for "in subrepo
MYSUBREPO" strings, TortoiseHg looks for these strings in error messages in
order to "linkify them" (i.e. convert "MYSUBREPO" into alink to the
corresponding subrepo).

The original string made it hard for a tool such as TortoiseHg to look for the
translated string on mercurial's output because the translated string contained
the error message itself. This meant that a regular expression was required to
ignore the error message part. With this change TortoiseHg can just get the
translated "(in subrepo %s)" string, substitute %s for the subrepo path (which
it gets from the subrepo exception) and simply search for the resulting string
(no regular expression needed, or at least a much simpler regular expression
could be used).

Additionaly, the existing string could lead a translator mistakenly assume that
it was possible invert the order of the %s (error and subrepo path) fields,
which would not work because the string interpolation was position based.

--HG--
extra : amend_source : 2388e69c22e92519c562501509536474adf332d8
largefiles: remove unused proto.refuseclient code

Should have been removed with other pre-1.9 code in 7c604d8c7e83.
largefiles: fix revert removing a largefile from a merge

Before revert could fail with:
  abort: .hglf/large@33fdd332ec64: not found in manifest!

The LookupError will now be caught and handled correctly.
largefiles: fix update from a merge with removed files

A situation with this case could happen after interrupting an update. Update
would fail with:
  abort: No such file or directory: $TESTTMP/f/.hglf/sub2/large6

Update from a merge without using clean is not possible anyway, so this patch
takes a step in the right direction so it gets as far as reporting the right
error.
archival: pass integer to struct.pack int field instead of float

If running in a context with warnings enabled and subsecond mtime it gave a
warning:
  DeprecationWarning: integer argument expected, got float
archival: avoid touching deprecated gzip name attribute

The existing workaround didn't work when no filename was specified.

If running in a context with warnings enabled and subsecond mtime it gave a
warning:
  DeprecationWarning: use the name attribute
clfilter: enforce hidden filtering on all repository accesses

We ensure all repositores created through `mercurial.hg.repository`
are "hidden" filtered. This is an even stronger enforcement than
5bb610f87d1d.

Citing Matt's response to changeset 5bb610f87d1d installing filtering
in dispatch:

> Unfortunately, this means that code that doesn't go through dispatch (ie all
> those crazy misguided people using Mercurial as a library) are going to see
> these hidden changesets.
>
> Might be better to instead install the filter in localrepo construction by
> default and disable it in dispatch.

--HG--
extra : amend_source : ff62d66b7ffa75260192b69b045df06658868ac5
perf: add perfbranchmap command

The command times the update of a branchmap from its nearest subset
or from scratch.

--HG--
extra : amend_source : 52be96e03b67bccf03521a745273a83ca0a1df39
branchmap: pass revision insteads of changectx to the update function

Creation of changectx objects is very slow, and they are not very
useful. We are going to drop them. The first step is to change the
function argument type.

--HG--
extra : amend_source : 338c6e0216ed6e88c36c782953ac838b7ceb2655
changelog: add a `branch` method, bypassing changectx

The only way to access the branch of a changeset is currently to
create a changectx object and access its `branch()` method. Creating
a new Python object is costly and has a huge impact on code doing
heavy access to `branch()` (like branchmap).

This change introduces a new method on changelog that allows direct
access to the branch of a revision. See the next changeset for impact.

--HG--
extra : amend_source : e93275d879a36d9fd7680b022699b591cc386477
branchmap: Save changectx creation during update

The newly introduced `branchmap` function allows us to skip the
creation of changectx objects. This speeds up the construction of
the branchmap.

On the mozilla repository (117293 changesets, 15490 mutable)

Before:
  ! impactable 19.9
  ! mutable 0.576
  ! unserved 3.16

After:
  ! impactable 7.03 (2.8x faster)
  ! mutable 0.352 (1.6x)
  ! unserved 1.15 (2.7x)

On the cpython repository (81418 changesets, 6418 mutable)

Before:
  ! impactable 15.9
  ! mutable 0.451
  ! unserved 0.861

After:
  ! impactable 6.55 (2.4x faster)
  ! mutable 0.170 (2.6x faster)
  ! unserved 0.289 (2.9x faster)

On the pypy repository (58852 changesets)

Before:
  ! impactable 13.6

After:
  ! impactable 6.17 (2.2x faster)

On my Mercurial repository (18295 changesets, 2210 mutable)

Before:
  ! impactable 23.9
  ! mutable 0.368
  ! unserved 0.057

After:
  ! impactable 1.31 (18x faster)
  ! mutable 0.042 (8.7x)
  ! unserved 0.025 (2.2x)

--HG--
extra : amend_source : d7365c6e21570966816cbf144637026b8eab34e3
changelog: please check-code and remove tabs

Tabs were introduced in 06185554e7e3.
localrepo: don't refresh filecache entries that aren't in __dict__

We call invalidate to remove properties from __dict__ because they're
possibly outdated and we'd like to check for a new version. Next time
the property is accessed the filecache mechanism checks the current stat
info with the one recorded at the last time the property was read, if
they're different it recreates the property.

Previously we refreshed the stat info on all properties in the filecache
when the lock is released, including properties that are missing from
__dict__. This is a problem because:

  l = repo.lock()
  repo.P          # stat info S for P is recorded in _filecache
  <changes are made to repo.P indirectly, e.g. underlying file is replaced>
                  # P's new stat info = S'
  l.release()     # filecache refreshes, records S' as P's stat info

At this point our filecache contains P with stat info S', but P's
version is from S, which is outdated.

The above happens during _rollback and strip. Currently we're wiping the
filecache and forcing everything to reload from scratch which works but
isn't the right solution.
localrepo: introduce destroying function
localrepo: update the branchmap when destroying nodes

This was previously called directly during strip. Moving it to destroying
also means that it'll be called through _rollback, which seems harmless.
localrepo: write the phasecache when destroying nodes