branchmap: enable caching for filtered version too The `_branchcache` attribute is turned into a dictionary. Key are filter name and value is a `branchcache` object. Unfiltered version is cached as `None` filter. The attribute is renamed to `_branchcaches` to avoid confusion with the previous one. Both old and new contents are dictionary even if their contents are different. I prefer possible extension code to crash right away instead of just messing the wrong dictionary. As all different caches work isolated to each other, this code keeps the previous behavior of using the unfiltered cache we nothing is filtered. This is a cheap way to have cache collaborate and nullify potential impact in the default case.

branchmap: report filtername when read fails Now that we can have multiple one, we need to know which filecache failed to be read from disk.

branchmap: use a different file name for filtered view of repo

clfilter: ensure unfiltered repo have a filtername attribute too That will allows to use `repo.filtername` for dispatch purpose.

branchmap: move the cache file name into a dedicated function Filtered view of the repo will want to write they file name in a different file.

branchmap: read and write key part related to filtered revision Now that we have a third part for the cache key we need to write and read it on disk. It is only written when there is filtered revision. This keep the format compatible with older version. Notes that, at this state, filtered repository does not use any disk caches yet.

check-code: disallow defunct <> operator Added a test for that and one other python3 check in test-check-code.t.

largefiles: stop using <> operator in favor of != <> has been deprecated for a while, and != is futureproof

commands: fix implicit tuple that is invalid syntax in Python3

check-code: disallow two-argument form of raise Using this old form makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

httpclient: apply change df9aea1def3e: remove use of two-argument raise

test-symlink-os-yes-fs-no.py: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

scmutil: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

url: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

win32: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

commandserver: clean up use of two-argument raise This makes any attempt to port to Python 3 harder, and the new syntax is supported in 2.4 already.

test-command-template.t: fix test so it all year This test started failing for me after midnight UTC on December 31st. Fixed it by specifying a date 7 years in the future more precisely (rather than just adding 8 to the year and specifying January 1st), which allows the test to pass both now and on 2012-12-01 at the same time.

cmdutil: make getgraphlogrevs limit-aware For a repository with over 400,000 changesets, this speeds up graphlog with a small limit by around 0.05 seconds (~50%).

cmdutil: stop pretending we can calculate revs for graphlog lazily cmdutil.getgraphlogrevs does a ton of work trying to build a graphlog lazily, and then cmdutil.graphlog comes along and destroys all of that. graphmod.dagwalker requires that it be given the full list of revs upfront so that it can perform filtering and tests against known revs. For a repository with over 400,000 changesets, this speeds up graphlog by around 0.02 seconds (~20% with a small limit).

cmdutil: store a local ref to repo.hiddenrevs in getgraphlogrevs On a repository with over 400,000 changesets, this speeds graphlog up by around 0.03 seconds (~20% with a small limit).

cmdutil: make getgraphlogrevs return revs in descending order

branchmap: takes filtered revision in account for cache calculation Tracking tipnode and tiprev is not enough to ensure validaty of the cache as they do not help distinguish a cache that ignored various revisions below tiprev. To detect such difference, we build a hash of all ignored revisions. This hash is then used when checking the validity of a cache for a repo.

branchmap: improve computation of target tip With revision filtering the effective revision number of "tip" may be lower than: len(changelog) - 1 We now use a more correct version preventing useless writing on disk in some case.

branchmap: improve invalid cache message when reading This factors out the generation of the message. This helps future error reporting when reading cache for filtered repository.