blackbox: send debug message to logger by core ui Since the core ui.log() may recurse into ui.log() through ui.debug(), it must guard against recursion. The ui extension class can finally be removed.

blackbox: change the way of deactivating the logger on write error This prepares for the upcoming code move. The recursion guard will be ported to the core ui.

match: remove obsolete catching of OverflowError Since 0f6a1bdf89fb (match: handle large regexes, 2007-08-19), we catch an OverflowError from the regex engine and split up the regex if that happens. In 59a9dc9562e2 (ignore: split up huge patterns, 2008-02-11), that was extended to raise an OverflowError in our code even if the regex engine doesn't raise it. It's unclear if there was a range of regex sizes where the OverflowError would be raised from the regex engine but that were still below the limit we added in our code. Either way, both limitations were probably removed in Python 2.7.4 when the regex code width was extended from 16bit to 32bit (or Py_UCS4) integer (thanks to Yuya for finding that out). If at least the first limitation was removed, we no longer should be using OverflowError for flow control, so this patch changes that. Differential Revision: https://phab.mercurial-scm.org/D5309

sparse: raise a move verbose index error from the C code If we don't like a value we should print it.

narrow: drop the bundle2 capability since we have server capabilities (BC) This patch drops the narrow bundle2 capabilities since we introduced narrow server capabilities which are more nice and now used everywhere. I am not sure what it can affect, so on safe side I marked this as BC. Also I removed the NARROWCAP constant as that kind of conflicts with the same name constant in wireprototypes.py. Differential Revision: https://phab.mercurial-scm.org/D4892

vfs: extract the audit path logic into a submethod This will make it possible to apply it in more cases.

subrepo-git: use an official origvfs when appropriate The origvfs has the auditor properly set and can move file without issue. The current code is currently working without errors because rename are not audited, yet.

revert: extract origvfs logic in a sub-function The subrepo's "revert" logic could benefit from it.

vfs: treat 'undo.' file the same as 'journal.' file They are the same kind of file, they are protected by the store lock, but directly lives inside the '.hg' directory. No warnings were ever raised about them because `vfs.rename` is not audited. Something we are trying to change.

perf: add a perfignore command The command is meant to benchmark operations related to hgignore. Right now the command is benchmarking the loading time of the hgignore rules.

py3: use pycompat.xrange instead of xrange xrange does not exists on Python 3. Differential Revision: https://phab.mercurial-scm.org/D5302

store: write fncache only once if there are both adds and removes Differential Revision: https://phab.mercurial-scm.org/D5307

perf: disable revlogs clearing in `perftags` by default This aligns things with what `perfbookmarks` does. I decided to disable the revlogs clearing by default to focus on the core logic by default, ignoring side effects. If we prefer to emphasize the side effect, we can instead keep this on in `perftags` and enable it by default in `perfbookmarks`.

perf: add a `clear-revlogs` flag to `perfbookmarks` This flag (off by default) makes it possible to enable the refresh of the changelog and revlog. This is useful to check for costly side effects of bookmark loading. Usually, these side effects are shared with other logics (eg: tags). example output in my mercurial repo (with 1 bookmark, so not a great example): $ hg perfbookmarks ! wall 0.000044 $ hg perfbookmarks --clear-revlogs ! wall 0.001380

tags: cache `repo.changelog` access when checking tags nodes The tags reading process checks if the nodes referenced in tags exist. Caching the access to `repo.changelog` provides a large speedup for repositories with many tags. running `hg perftags` in a large private repository before: ! wall 0.393464 comb 0.390000 user 0.330000 sys 0.060000 (median of 25) after: ! wall 0.267711 comb 0.270000 user 0.210000 sys 0.060000 (median of 38)

perf: add a `clear-revlogs` flag to `perftags` This flag (on by default) makes it possible to disable the refresh of the changelog and revlog. This is useful to check for the time spent in the core tags logic without the associated side effects. Usually, these side effects are shared with other logics (eg: bookmarks). Example output in my Mercurial repository $ hg perftags ! wall 0.017919 comb 0.020000 user 0.020000 sys 0.000000 (best of 141) $ hg perftags --no-clear-revlogs ! wall 0.012982 comb 0.010000 user 0.010000 sys 0.000000 (best of 207)

perf: stop creating new revlog by hand in perftags It's better to let the repository logic create its own object. We now just clear the cache. New object will be automatically created from there.

revlog: update the documentation for `trim_endidx` The function role drifted since the function was commented.

revlog: properly detect corrupted revlog in `index_get_length` Pointed out by Yuya Nishihara.

perf: rename `perfhelper-tracecopies` to `perfhelper-pathcopies` The command it supports is called `perfpathcopies`. It seems better to align the names.

perf: add a docstring to `perfpathcopies` This will help people to find this command.

revlog: update the docstring of `ancestors` to match reality Code using this method expect the revision to be (reverse) sorted. As pointed by Yuya Nishihara, the docstring should reflect that.

remotefilelog: fix typo in docstring Differential Revision: https://phab.mercurial-scm.org/D5306

store: append to fncache if there are only new files to write Before this patch, if we have to add a new entry to fncache, we write the whole fncache again which slows things down on large fncache which have millions of entries. Addition of a new entry is common operation while pulling new files or commiting a new file. This patch adds a new fncache.addls set which keeps track of the additions happening and store them. When we write the fncache, we will just read the addls set and append those entries at the end of fncache. We make sure that the entries are new entries by loading the fncache and making sure entry does not exists there. In future if we can check if an entry is new without loading the fncache, that will speed up things more. Performance numbers for commiting a new file: mercurial repo before: 0.08784651756286621 after: 0.08474504947662354 mozilla-central before: 1.83314049243927 after: 1.7054164409637451 netbeans before: 0.7953150272369385 after: 0.7202838659286499 pypy before: 0.17805707454681396 after: 0.13431048393249512 In our internal repo, the performance improvement is in seconds. I have used octobus's ASV perf benchmark thing to get the above numbers. I also see some minute perf improvements related to creating a new commit without a new file, but I believe that's just some noise. Differential Revision: https://phab.mercurial-scm.org/D5301