remotefilelog: use progress helper in shallowbundle Differential Revision: https://phab.mercurial-scm.org/D5379

remotefilelog: use progress helper in repack Differential Revision: https://phab.mercurial-scm.org/D5378

remotefilelog: use progress helper in remotefilelogserver Differential Revision: https://phab.mercurial-scm.org/D5377

remotefilelog: use progress helper in basestore Differential Revision: https://phab.mercurial-scm.org/D5376

remotefilelog: use progress helper when analyzing repos Differential Revision: https://phab.mercurial-scm.org/D5375

fastannotate: use progress helper Differential Revision: https://phab.mercurial-scm.org/D5374

debugbuildannotatecache: use progress helper Differential Revision: https://phab.mercurial-scm.org/D5373

upgrade: clarify "aggressivemergedelta" handling We rename "aggressivemergedelta" argument to "forceaggressivemergedelta". The previous argument naming could infer an absolute control on the behavior. However, the code show we respect the config option if set.

upgrade: test that fncache is valid after repository upgrade The behavior was correct. Now it is correct and tested.

tests: update `rm` invocation for new location of checklink This should fix the test on FreeBSD. Differential Revision: https://phab.mercurial-scm.org/D5387

bookflow: new extension for bookmark-based branching This extension should be helpful for feature branches - based workflows. At my company we first considered branches, but weren't sure about creating a lot of permanent objects. We tried bookmarks, but found some scenarios to be difficult to control. The main problem, was the active bookmark being moved on update. Disabling that made everything a lot more predictable. Bookmarks move on commit, and updating means switching between them. The extension also implements a few minor features to better guide the workflow: - hg bookmark NAME can be ambiguous (create or move), unlike hg branch. The extension requires -rev to move. - require an active bookmark on commit. - some bookmarks can be protected (like @), useful for teams, that require code reviews. - block creation of new branches. The initial implementation requires no changes in the core, but it does rely on some implementation details. I thought it may be useful to discuss the functionality first, and then focus making the code more robust. Differential Revision: https://phab.mercurial-scm.org/D4312

rust: make clean takes care of rust/target This isn't the prettiest way of doing it, but it doesn't require looking up cargo, or wondering whether that should be part of setup.py clean. Differential Revision: https://phab.mercurial-scm.org/D5369

rust: rename local variables in AncestorsIterator::next It was confusing to have p1 and parents.1 ; (p1, p2) is clearer. Differential Revision: https://phab.mercurial-scm.org/D5365

tests: stabilize test-inherit-mode.t on FreeBSD and macOS again This is the same fix as 90e26ef4cbb1, just repeated on the new file location. Differential Revision: https://phab.mercurial-scm.org/D5371

tests: drop redundant "#if execbit" from test-rebase-inmemory.t The whole file is already guarded by "#require execbit". Differential Revision: https://phab.mercurial-scm.org/D5366

narrow: don't resurrect old commits when narrowing (don't strip obsmarkers) If you have an old obsolescence-chain of commits that has been pruned and you narrow your repo so that some of those commits get stripped (because they affected the removed paths), then we would currently resurrect the commit that came before (along the obsmarker chain) the last stripped commit. That happens by the usual rules for obsmarker-stripping. However, it's quite surprising when it happens when you narrow your repo. This patch makes narrowing not strip obsmarkers. Differential Revision: https://phab.mercurial-scm.org/D5364

commandserver: turn server debug messages into logs They were ui.debug() just because commandserver.log() was noop if no client connected.

commandserver: add config knob for various logging options The default rotating options are copied from the blackbox extension.

commandserver: expand log path for convenience This allows us to set the log path relative to $XDG_RUNTIME_DIR, for instance. [cmdserver] log = $XDG_RUNTIME_DIR/chg/server.log

commandserver: switch logging facility to ui.log() interface The "pager subcommand" message is removed since ui isn't accessible there. I think that's okay as cmdtable[cmd]() will call attachio() and some debug message will be printed.

commandserver: install logger to record server events through canonical API The global commandserver.log() will be replaced with this.

commandserver: enable logging when server process started This allows us to keep track of server events before client connects to the server. Tests will be added later. Currently there's no log() call to check if things are working well.

test-commandserver: change way of triggering early crash Future patches will move the logging facility out of the server class, so cmdserver.log can't be (ab)used for this purpose. Instead, let's hook the factory function to raise exception.

loggingutil: add basic logger backends These classes will be used in command server. They are similar to the blackboxlogger, but it can't be factored out since the blackbox is so tightly coupled with a repo object.

hgweb: register web.comparisoncontext to the config table This was caught in some server side logging added to debug py3 issues.

merge with stable

Added signature for changeset 1c8c54cf9725

Added tag 4.8.1 for changeset 1c8c54cf9725

rebase: fix path auditing to audit path relative to repo root (issue5818) Before this patch, when rebasing a file called "foo/bar", we would check e.g. if "/foo" (i.e. rooted at the file system root) was a symlink. Differential Revision: https://phab.mercurial-scm.org/D5361

tests: show bad path auditing in in-memory rebase Thanks to Yuya for providing this test case in https://bz.mercurial-scm.org/show_bug.cgi?id=5818. Differential Revision: https://phab.mercurial-scm.org/D5368

tests: add a missing "cd .." to test-rebase-inmemory.t Differential Revision: https://phab.mercurial-scm.org/D5367

rust: fix possible out-of-bounds read through index_get_parents() index_get_parents() is an internal function, which doesn't check if the specified rev is valid. If rustlazyancestors() were instantiated with an invalid stoprev, it would access to invalid memory region. This is NOT a security fix as there's no Python code triggering the bug, but included in this series to not give a notion about the memory issue fixed by the previous patch.

revlog: fix out-of-bounds access by negative parents read from revlog (SEC) 82d6a35cf432 wasn't enough. Several callers don't check negative revisions but for -1 (nullrev), which would directly lead to out-of-bounds read, and buffer overflow could follow. RCE might be doable with carefully crafted revlog structure, though I don't think this would be useful attack surface.

rust: peek_mut optim for lazy ancestors This is one of the two optimizations that are also present in the Python code: replacing pairs of pop/push on the BinaryHeap by single updates, hence having it under the hood maintain its consistency (sift) only once. On Mozilla central, the measured gain (see details below) is around 7%. Creating the PeekMut object by calling peek_mut() right away instead of peek() first is less efficient (gain is only 4%, stats not included). Our interpretation is that its creation has a cost which is vasted in the cases where it ends by droping the value (Peekmut::pop() just does self.heap.pop() anyway). On the other hand, the immutable peek() is very fast: it's just taking a reference in the underlying vector. The Python version still has another optimization: if parent(current) == current-1, then the heap doesn't need to maintain its consistency, since we already know that it's bigger than all the others in the heap. Rust's BinaryHeap doesn't allow us to mutate its biggest element with no housekeeping, but we tried it anyway, with a copy of the BinaryHeap implementation with a dedicaded added method: it's not worth the technical debt in our opinion (we measured only a further 1.6% improvement). One possible explanation would be that the sift is really fast anyway in that case, whereas it's not in the case of Python, because it's at least partly done in slow Python code. Still it's possible that replacing BinaryHeap by something more dedicated to discrete ordered types could be faster. Measurements on mozilla-central: Three runs of 'hg perfancestors' on the parent changeset: Moyenne des médianes: 0.100587 ! wall 0.100062 comb 0.100000 user 0.100000 sys 0.000000 (best of 98) ! wall 0.135804 comb 0.130000 user 0.130000 sys 0.000000 (max of 98) ! wall 0.102864 comb 0.102755 user 0.099286 sys 0.003469 (avg of 98) ! wall 0.101486 comb 0.110000 user 0.110000 sys 0.000000 (median of 98) ! wall 0.096804 comb 0.090000 user 0.090000 sys 0.000000 (best of 100) ! wall 0.132235 comb 0.130000 user 0.120000 sys 0.010000 (max of 100) ! wall 0.100258 comb 0.100300 user 0.096000 sys 0.004300 (avg of 100) ! wall 0.098384 comb 0.100000 user 0.100000 sys 0.000000 (median of 100) ! wall 0.099925 comb 0.100000 user 0.100000 sys 0.000000 (best of 98) ! wall 0.133518 comb 0.140000 user 0.130000 sys 0.010000 (max of 98) ! wall 0.102381 comb 0.102449 user 0.098265 sys 0.004184 (avg of 98) ! wall 0.101891 comb 0.090000 user 0.090000 sys 0.000000 (median of 98) Mean of the medians: 0.100587 On the present changeset: ! wall 0.091344 comb 0.090000 user 0.090000 sys 0.000000 (best of 100) ! wall 0.122728 comb 0.120000 user 0.110000 sys 0.010000 (max of 100) ! wall 0.093268 comb 0.093300 user 0.089300 sys 0.004000 (avg of 100) ! wall 0.092567 comb 0.100000 user 0.090000 sys 0.010000 (median of 100) ! wall 0.093294 comb 0.080000 user 0.080000 sys 0.000000 (best of 100) ! wall 0.144887 comb 0.150000 user 0.140000 sys 0.010000 (max of 100) ! wall 0.097708 comb 0.097700 user 0.093400 sys 0.004300 (avg of 100) ! wall 0.094980 comb 0.100000 user 0.090000 sys 0.010000 (median of 100) ! wall 0.091262 comb 0.090000 user 0.080000 sys 0.010000 (best of 100) ! wall 0.123772 comb 0.130000 user 0.120000 sys 0.010000 (max of 100) ! wall 0.093188 comb 0.093200 user 0.089300 sys 0.003900 (avg of 100) ! wall 0.092364 comb 0.100000 user 0.090000 sys 0.010000 (median of 100) Mean of the medians is 0.0933 Differential Revision: https://phab.mercurial-scm.org/D5358

fuzz: grep away HAVE_GETC_UNLOCKED in pyconfig.h to avoid msan badness Per discussion with Greg Smith and the patches on https://bugs.python.org/issue35214. This, combined with the previous patch, fixes msan builds on oss-fuzz. Differential Revision: https://phab.mercurial-scm.org/D5363

fuzz: more correctly specify CFLAGS and LDFLAGS when building Python Gets us closer to a working msan build alongside our asan build. Differential Revision: https://phab.mercurial-scm.org/D5362

tests: stabilize test-blackbox.t on Windows I didn't look into why the error is more detailed, but that seems like it's a good thing (other than for recording tests).

tests: stabilize for recent wcache changes This goes with 47e3f554df35::d5622dfe4ba3. I'm not sure if it was really expected that there would be no wcache directory if neither execbit nor symlink is supported.

extdiff: avoid double backslashes in the displayed tool path on Windows This shows the tool path in the help, and changed in 67b180c0e263. uirepr() already does the same thing, but that undoes the mangling in its call to repr().

contrib: add a helper script that help to build interesting repositories The script is dedicated to building a couple of repositories that should be interesting to run discovery from one another. It seems a common enough need to contribute it upstream.

py3: listify filter() to call len() on it Differential Revision: https://phab.mercurial-scm.org/D5354

rebase: fix dir/file conflict detection when using in-mem merge Differential Revision: https://phab.mercurial-scm.org/D5360

tests: show that in-mem rebase does not find path dir/file conflicts Differential Revision: https://phab.mercurial-scm.org/D5359

extdiff: register the configuration generated commands with a help category Otherwise, 'extdiff' shows up under file management and the rest of the commands are at the bottom under 'Uncategorized'.

loggingutil: document openlogfile() This function will be used later for command-server logging.

loggingutil: extract openlogfile() and proxylogger to new module This module isn't placed under the "utils" package since it needs "ui" to process things. It's called "loggingutil", not "logutil" because the word "log" is too obscure in our codebase.

blackbox: pass in options to _openlogfile() as arguments This prepares for extracting utility function from the blackbox module.

blackbox: just try writing to repo.vfs and update lastlogger on success This is simpler and more robust. Before, an empty ".hg" directory would be created if it's removed after checking vfs.isdir('.').

vfs: add option to not create parent directories implicitly In blackbox, we don't want to create a ".hg" directory by mistake. This provides a race-safe option to achieve that.

repo: add a `wcachevfs` to access the `.hg/wcache/` directory This wvfs will allow us to migrate various cache to the new `wcache` directory. Helping with cache issues with "share".

cache: create `wcache` directory at init time The cache directory will be needed very quickly, so it seems simpler to create it early to make sure it has the same owner and permission than the other directory in the repository.

cache: create `cache` directory at init time The cache directory will be needed very quickly, so it seems simpler to create it early to make sure it has the same owner and permission than the other directory in the repository.

check-exec: write file in 'wcache' instead of 'cache' Some cache are relevant or affected by the working copy used. So the `.hg/cache` directory is not the best place for them because multiple shared repository can end up fighting over them. To address this issue, we introduce a new 'wcache' directory to host this kind of cache. The first user are the `checkisexec` type file. These files describe property of the working copy and fit the use-case well.

rebase: abort in-mem rebase if there's a dirty merge state In-memory merge uses the on-disk merge state, so we should not allow it run in-memory merge when the merge state is not clean. We should probably not use the on-disk merge state when running in-memory merge, but chaning that is not suitable for the stable branch. Differential Revision: https://phab.mercurial-scm.org/D5357

rebase: preserve working copy when redoing in-mem rebase on disk When in-memory rebase runs into conflicts, we retry it on disk. But before we do that, we abort the in-memory rebase. That is done because even though it's mostly in memory, there are still a few state files written (e.g. the merge state). We should make it not write those files so we don't need to abort, but for the stable branch, let's explicitly clear the state we need to clear instead of running the usual abort code. Differential Revision: https://phab.mercurial-scm.org/D5356

tests: show that in-mem rebase falling back loses state Both working copy changes and the merge state is lost when in-memory rebase falls back to on-disk mode. Differential Revision: https://phab.mercurial-scm.org/D5355

commandserver: get around ETIMEDOUT raised by selectors2 selector.select() should exits with an empty event list on timed out, but selectors2 raises OSError if timeout expires while recovering from EINTR. Spotted while debugging new chg feature.

selectors2: backport minimal fix of timeout handling from 2.0.1 The original code would raise TypeError since OSError() doesn't support keyword arguments. We can't simply import the selectors 2.0.1, which still spawns "uname -p" through platform.system(). We could switch to the unreleased version, but I decided to not right now to minimize the change.

mmapindex: set default to 1MB mmapping index is more efficient if we only need a small part of it. The 1MB value has been picked arbitrarily, a lower value might be better. On a large repository with a 60MB index, we see the following performance gain: hg perfindex before: ! wall 0.032023 comb 0.040000 user 0.000000 sys 0.040000 (best of 100) after: ! wall 0.000196 comb 0.000000 user 0.000000 sys 0.000000 (best of 1060) The speed boost benefit all cases, including the one where the full index needs to be parsed. hg perfindex --rev 0 before: ! wall 0.040673 comb 0.030000 user 0.000000 sys 0.030000 (best of 100) after ! wall 0.010713 comb 0.020000 user 0.010000 sys 0.010000 (best of 212) This gain reflect in higher level operation: hg perfbookmarks --clear-revlogs before: ! wall 0.161339 comb 0.160000 user 0.130000 sys 0.030000 (best of 56) after: ! wall 0.123228 comb 0.120000 user 0.120000 sys 0.000000 (best of 68)

mmapindex: move the 'mmapindexthreshold' option out of experimental The option is useful and should be advertised more. We move it out of experimental as a first step. The `storage` section is selected as this is related to how the storage is accessed. A new 'performance' section might be more appropriate. We move from 'mmapindexthreshold` to `mmap-threshold` as non-index item are also suitable for mmap (eg: the rev-branch-cache). If relevant, we can introduce sub-option `mmap-threshold.revlog-index` later.

perf: add a --rev attribute to perfindex This allow for benchmarking the time necessary to look for other version than the tip.

perf: update perfindex to be more realistic The previous code was creating a revlog manually, we now use the actual `localrepo` method to create it. We have to jump though extra hops to work around the impact of filecache.

match: drop unnecessary wrapping of regex in group It seems the regexes have been wrapped in an unnamed group since b6c42714d900 (Add locate command., 2005-07-05). In that commit, the grouping was needed because there was a "head" ('^') added before the group and a "tail" (os.sep) added after it. It seems the head was moved inside the group in 1c0c413cccdd (Get add and locate to use new repo and dirstate walk code., 2005-07-18) and the tail was moved inside the group in 89985a1b3427 (Clean up walk and changes code to use normalised names properly., 2005-07-31), So it seems to me that we've carried around the unnecessary group for 13 years. This patch removes it. Differential Revision: https://phab.mercurial-scm.org/D5352

match: use _BASE_SIZE instead of magic value 4 Differential Revision: https://phab.mercurial-scm.org/D5351

match: make "groupsize" include the trailing "|" I think this is a little easier to follow and it will simplify later patches too. Differential Revision: https://phab.mercurial-scm.org/D5350

match: fix an unaligned (but harmless) indent Differential Revision: https://phab.mercurial-scm.org/D5349

match: raise an Abort error instead of OverflowError This case of OverflowError (one single pattern being too large) has never been properly caught in the past.

match: avoid translating glob to matcher multiple times for large sets For hgignore with many globs, the resulting regexp might not fit under the 20K length limit. So the patterns need to be broken up in smaller pieces. Before this change, the logic was re-starting the full process from scratch for each smaller pieces, including the translation of globs into regexp. Effectively doing the work over and over. If the 20K limit is reached, we are likely in a case where there is many such glob, so exporting them is especially expensive and we should be careful not to do that work more than once. To work around this, we now translate glob to regexp once and for all. Then, we assemble the resulting individual regexp into valid blocks. This raises a very significant performance win for large `.hgignore file`: Before: ! wall 0.153153 comb 0.150000 user 0.150000 sys 0.000000 (median of 66) After: ! wall 0.059793 comb 0.060000 user 0.060000 sys 0.000000 (median of 100)

match: extract function that group regexps

match: test for overflow error in pattern If a single pattern is too large to handle, we raise an exception. This case is now doctested.

match: extract a literal constant into a symbolic one

tests: apply binary mode to output in seq.py I noticed this when playing with running tests using WSL, and iterating over the output yielded '0\r', '1\r',... Most of the other *.py tools do this, and `seq` on MSYS lacks '\r' in the output, so this is more consistent.

perf: add a `--clear-caches` to `perfbranchmapupdate` This flag will help to measure the time we spend loading various cache that support the branchmap update. Example for an 500 000 revisions repository: hg perfbranchmapupdate --base 'not tip' --target 'tip' ! wall 0.000860 comb 0.000000 user 0.000000 sys 0.000000 (best of 336) hg perfbranchmapupdate --base 'not tip' --target 'tip' --clear-caches ! wall 0.029494 comb 0.030000 user 0.030000 sys 0.000000 (best of 100)

perf: start from an existing branchmap if possible If the --base set if a superset of one of the cached branchmap, we should use as a starting point. This greatly help the overall runtime of `hg perfbranchmapupdate` For example, for a repository with about 500 000 revisions, using this trick make the command runtime move from about 200 second to about 10 seconds. A 20x gain.

perf: rely on repoview for perfbranchmapupdate Using 'repoview' matching the base and target subset make the benchmark more realistic. It also unlocks optimization to make the command initialization faster.

perf: pre-indent some code in `perfbranchmapupdate` This make the next patch easier to read.

perf: add a `perfbranchmapupdate` command This command benchmark the time necessary to update the branchmap between two sets of revisions. This changeset introduce a first version, doing nothing fancy regarding cache or other internal details.

push: config option to control behavior when pushing to a publishing server Pushing to a publishing server by mistake can lead to a difficult situation to solve because evolution doesn't work on public changesets. This new experimental config tries to help avoiding unintentionally (or at least being aware of) pushing to publishing remotes. `hg push --publish` can be used to make push succeed even when auto-publish is set to 'abort'.

narrowcommands: remove an unrequired `repo.narrowpats` call We call that few lines above and do nothing significant in between which can change the narrowpats. So let's use values returned by that call. Differential Revision: https://phab.mercurial-scm.org/D5348

manifest: reject lines shorter than 42 bytes, not 22 Yuya correctly spotted during the review of f27f8e9ef1e73 that we're dealing with hexlified hashes here, and so it should be 42 bytes not 22. Differential Revision: https://phab.mercurial-scm.org/D5347

blackbox: initialize logger with repo instance The blackboxlogger is unusable without a repo. Let's simply initialize it with a repo instance.

blackbox: do not nullify repo to deactivate the logger on failure The _repo will be a mandatory attribute. Instead, make the logger to not track any events.

blackbox: extract global last logger to proxylogger class So the blackboxlogger can be instantiated with a repo.

ui: pass in bytes opts dict to logger.log() This is the convention of the Mercurial API.

ui: pass in formatted message to logger.log() This makes sure that all logger instances will handle the message arguments properly.

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

py3: fix couple of division operator to do integer divison Differential Revision: https://phab.mercurial-scm.org/D5305

py3: use dict.items() instead of dict.iteritems() dict.iteritems() does not exist on Python 3. Differential Revision: https://phab.mercurial-scm.org/D5304

py3: convert strings to bytes in tests/test-remotefilelog-histpack.py Differential Revision: https://phab.mercurial-scm.org/D5303

py3: replace str() with pycompat.bytestr() or ('%d' % int) After this patch, test-fastannotate-diffopts.t is about to pass. There are some extra newlines in the output. Differential Revision: https://phab.mercurial-scm.org/D5300

perf: add a `--timing` argument to `perfhelper-tracecopies` The new argument will help picking better pair for benchmarking. See documentation for details.

ui: manage logger instances and event filtering by core ui The setup code in blackbox needs more tweaks since it has lots of black magics. I'll fix them by follow-up patches. To be clear, the goal of this series is to provide a proper way for command server to install its own logger. I need it to debug in-memory repository cache.

extensions: add "uipopulate" hook, called per instance, not per process In short, this is the "reposetup" function for ui. It allows us to modify ui attributes without extending ui.__class__. Before, the only way to do that was to abuse the config dictionary, which is copied across ui instances. See the next patch for usage example.

hgweb: load globally-enabled extensions explicitly Before, extensions were loaded as a side effect of hg.repository() if the hgweb was executed as a CGI/WSGI. I want to make it explicit so that another ui hook can be inserted after extensions.loadall().

tests: sniff for libfuzzer actually being available in test-fuzz-targets.t When I upgraded the FreeBSD buildbot to 11.2 it seems we picked up clang6, but the default clang on FreeBSD doesn't include libfuzzer. I can't find a way to sniff for libfuzzer without running a compile, so here we are. Differential Revision: https://phab.mercurial-scm.org/D5270

tests: sniff for /usr/local/bin/gmake and use it in test-fuzz-targets.t This isn't as robust as it probably should be, but for now it'll get the job done on the buildbots. Differential Revision: https://phab.mercurial-scm.org/D5269

tests: stabilize test-inherit-mode.t on FreeBSD and macOS (issue6026) Symbolic links are funny permissions-wise, but on the linked issue Yuya has convinced me that we can ignore this permissions issue on macOS (FreeBSD allows setting permissions bits but ignores them) and we'll be in fine shape.