shelve: add test clearly demonstrating that the conflict labels are backwards Differential Revision: https://phab.mercurial-scm.org/D8139

import: don't ignore `--secret` when `--bypass` is specified Differential Revision: https://phab.mercurial-scm.org/D8126

phabricator: fix a phabsend crash when processing a renamed binary This was a trivial fix, and some more tests are added to cover binary files. Since the old filecontext is passed in, the old name is still available. But I noticed some weirdness around what it marked as binary and not, and what is viewable in Phabricator. Those things have been flagged, and will probably take some digging. Differential Revision: https://phab.mercurial-scm.org/D8133

test: pin the number of CPU for issue4074 tests On machine with an hundreds of CPUs, the "user" CPU time reported can be inflated by the status steps. Since the test especially focus on the diff computation, we restrict the number of CPU to avoid potential issues. Differential Revision: https://phab.mercurial-scm.org/D8112

rust-dirstatemap: add `NonNormalEntries` class This fix introduces the same encapsulation as the `copymap`. There is no easy way of doing this any better for now. `hg up -r null && time HGRCPATH= HGMODULEPOLICY=rust+c hg up tip` on Mozilla Central, (not super recent, but it doesn't matter): Before: 7:44,08 total After: 1:03,23 total Pretty brutal regression! This is a graft on stable of cf1f8660e568 Differential Revision: https://phab.mercurial-scm.org/D8111

rust-dirstatemap: cache non normal and other parent set Performance of `hg update` was significantly worse since the introduction of the Rust `dirstatemap`. This regression was noticed by Valentin Gatien-Baron when working on a large repository, as it goes unnoticed for smaller repositories like Mercurial itself. This fix introduces the same getter/setter mechanism at `hg-core` level as for `set/get_dirs`. While this technique is, as previously discussed, quite suboptimal, it fixes an important enough problem. Refactoring `hg-core` to use the typestate pattern could be a good approach to improving code quality in a future patch. This is a graft of stable of 83b2b829c94e Differential Revision: https://phab.mercurial-scm.org/D8110

chgserver: spawn new process if schemes change The schemes extension updates hg.schemes table. It's technically possible for hg.repository() to look for e.g. ui.schemes instead of depending on module-local table, but I don't think the change would make much sense since [schemes] is usually specified in ~/.hgrc and thus it can be considered static data.

tests: accept new bzr message about switching branches The new version apparently prints "Switched to branch at " instead of "Switched to branch: ". Differential Revision: https://phab.mercurial-scm.org/D8106

nodemap: keep track of the docket for loaded data To perform incremental update of the on disk data, we need to keep tracks of some aspect of that data. Differential Revision: https://phab.mercurial-scm.org/D7885

nodemap: introduce an explicit class/object for the docket We are about to add more information to this docket, having a clear location to stock them in memory will help. Differential Revision: https://phab.mercurial-scm.org/D7884

nodemap: keep track of the ondisk id of nodemap blocks If we are to incrementally update the files, we need to keep some details about the data we read. Differential Revision: https://phab.mercurial-scm.org/D7883

nodemap: provide the on disk data to indexes who support it Time to start defining the API and prepare the rust index support. We provide a method to do so. We use a distinct method instead of passing them in the constructor because we will need this method anyway later (to refresh the mmap once we update the data on disk). Differential Revision: https://phab.mercurial-scm.org/D7847

nodemap: all check that revision and nodes match in the nodemap More check is always useful. Differential Revision: https://phab.mercurial-scm.org/D7846

nodemap: add basic checking of the on disk nodemap content The simplest check it so verify we have all the revision we needs, and nothing more. Differential Revision: https://phab.mercurial-scm.org/D7845

nodemap: code to parse the persistent binary nodemap data We now have code to read back what we persisted. This will be put to use in later changesets. Differential Revision: https://phab.mercurial-scm.org/D7844

nodemap: move the iteratio inside the Block object Having the iteration inside the serialization function does not help readability. Now that we have a `Block` object, let us move that code there. Differential Revision: https://phab.mercurial-scm.org/D7843

nodemap: use an explicit "Block" object in the reference implementation This will help us to introduce some test around the data currently written on disk. Differential Revision: https://phab.mercurial-scm.org/D7842

nodemap: add a optional `nodemap_add_full` method on indexes This method can be used to obtains persistent data for a full nodemap. The end goal is for some index implementation to managed the nodemap serialization them selves (eg: the rust implementation) Differential Revision: https://phab.mercurial-scm.org/D7841

nodemap: add a (python) index class for persistent nodemap testing Using the persistent nodemap require a compeling performance boost and an existing implementation. The benefit of the persistent nodemap for pure python code is unclear and we don't have a C implementation for it. Yet we would like to actually start testing it in more details and define an API for using that persistent nodemap. We introduce a new `devel` config option to use an index class dedicated to Nodemap Testing. This feature is "pure" only because having using a pure-python index with the `cext` policy proved more difficult than I would like. There is nothing going on in that class for now, but the coming changeset will change that. Differential Revision: https://phab.mercurial-scm.org/D7840

nodemap: delete older raw data file when creating a new ones When we write new full files, it replace an older one with a different name. We add the associated cleanup for the older file to be removed after the transaction. We delete all file matching the expected pattern to give use extra chance to delete orphan files we might have failed to delete earlier. Note: eventually we won't rewrite all data for each transaction. This is coming in later changesets. Differential Revision: https://phab.mercurial-scm.org/D7839

nodemap: use an intermediate "docket" file to carry small metadata This intermediate file will make mmapping, transaction and content validation easier. (Most of this usefulness will arrive gradually in later changeset). In particular it will become very useful to append new data are the end of raw file instead of rewriting on the file on each transaction. See in code comments for details. Differential Revision: https://phab.mercurial-scm.org/D7838

nodemap: only use persistent nodemap for non-inlined revlog Revlog are inlined while they are small (to avoid having too many file to deal with). The persistent nodemap will only provides a significant boost for large enough revlog index. So it does not make sens to add an extra file to store nodemap for small revlog. We could consider inclining the nodemap data inside the revlog itself, but the benefit is unclear so let it be an adventure for another time. Differential Revision: https://phab.mercurial-scm.org/D7837

nodemap: add a function to read the data from disk This changeset is small and mostly an excuse to introduce an API function reading the data from disk. Differential Revision: https://phab.mercurial-scm.org/D7836

nodemap: write nodemap data on disk Let us start writing data on disk (so that we can read it from there later). This series of changeset is going to focus first on having data on disk and updating it. Right now the data is written right next to the revlog data, in the store. We might move it to cache (with proper cache validation mechanism) later, but for now revlog have a storevfs instance and it is simpler to us it. The right location for this data is not the focus of this series. Differential Revision: https://phab.mercurial-scm.org/D7835

nodemap: have some python code writing a nodemap in persistent binary form This python code aims to be as "simple" as possible. It is a reference implementation of the data we are going to write on disk (and possibly, later a way for pure python install to make sure the on disk data are up to date). It is not optimized for performance and rebuild the full data structure from the index every time. This is a stepping stone toward a persistent nodemap on disk. Differential Revision: https://phab.mercurial-scm.org/D7834

cleanup: re-run black on the codebase Looks like a few patches have landed without having been blackened. I strongly suspect I should write a patch for baymax that blackens things on the way in... # skip-blame automatic formatting Differential Revision: https://phab.mercurial-scm.org/D8104

rust-re2: add wrapper for calling Re2 from Rust This assumes that Re2 is installed following Google's guide. I am not sure how we want to integrate it in the project, but I think a follow-up patch would be more appropriate for such work. As it stands, *not* having Re2 installed results in a compilation error, which is a problem as it breaks install compatibility. Hence, this is gated behind a non-default `with-re2` compilation feature. Differential Revision: https://phab.mercurial-scm.org/D7910

rust-filepatterns: add support for `include` and `subinclude` patterns This prepares a future patch for `IncludeMatcher` on the road to bare `hg status` support. Differential Revision: https://phab.mercurial-scm.org/D7909

rust-filepatterns: improve API and robustness for pattern files parsing Within the next few patches we will be using this new API. Differential Revision: https://phab.mercurial-scm.org/D7908

tests: add workaround for bzr bug This started failing for me today. I guess my bzr was upgraded. Differential Revision: https://phab.mercurial-scm.org/D8105