dirstate: pre-indent some of the backup code This will make the next changeset clearer.

debugrebuilddirstate: double check that no transaction is open Since transaction impact dirstate write, we make sure nobody is trying anything strange with this internal command.

dirstate: explicitly write the dirstate after `debugrebuilddirstate` I am working on making the dirstate write patterns more predictable. This patch is part of a small series of similar patches that adds a explicit dirstate write in a handful of location where the dirstate is updated "a bit in a strange way". With this explicit write, we are no longer relying on implicite write of the dirstate on `wlock` release. This make the world a better place.

dirstate: explicitly write the dirstate after `keyword` "overwrite" I am working on making the dirstate write patterns more predictable. This patch is part of a small series of similar patches that adds a explicit dirstate write in a handful of location where the dirstate is updated "a bit in a strange way". With this explicit write, we are no longer relying on implicite write of the dirstate on `wlock` release. This make the world a better place.

dirstate: explicitly write the dirstate after `eol` dirstate manipulation I am working on making the dirstate write patterns more predictable. This patch is part of a small series of similar patches that adds a explicit dirstate write in a handful of location where the dirstate is updated "a bit in a strange way". With this explicit write, we are no longer relying on implicite write of the dirstate on `wlock` release. This make the world a better place.

dirstate: explicitly write the dirstate after mq dirstate rebuild I am working on making the dirstate write patterns more predictable. This patch is part of a small series of similar patches that adds a explicit dirstate write in a handful of location where the dirstate is updated "a bit in a strange way". With this explicit write, we are no longer relying on implicite write of the dirstate on `wlock` release. This make the world a better place.

transaction: quietly rollback if no other changes than temporary files If no actual change have been made, we don't really need to roll them back. We only have to cleanup some temporary files and it seems reasonable to do that quietly. This will help us to use the transaction in wider context¹ without impacting the user experience. [1] as in Python context managers that lives longer.

transaction: run abort callback in all cases Previously, these possibly important callback were "forgotten" when running a quick rollback. This is now fixed, as the tests shown.

transaction: clarify the "quick abort" scenario Right now, the transaction has a code-pass to do a "quick abort" that skip most¹ (too much) of the logic when the right condition are detected² We are about to improve this logic in multiple aspect. We clarify the code first. The conditional return in `_can_quick_abort` looks a bit weird because we are about to make them more complex very soon. [1] actually too much [2] actually not often enough

test: use a more direct form of interruption in fncache "recover" testing The previous test was relying on implementation details and harder to maintain. The new version is closer to the initial intend : "What happens if the process die without cleanup". This change is motivated by further changes around the transaction and dirstate logic that would break the fragile equilibrium that existed before this patch. Making this change early make it easier to review on its own and remove noise in future larger changes.

test: use a more direct approach to test racy mutation The previous test was relying on implementation details and harder to maintain. The new version is closer to the initial intend : "What happens the file get overwritten from under the current process" This change is motivated by further changes around the transaction and dirstate logic that would break the fragile equilibrium that existed before this patch. Making this change early make it easier to review on its own and remove noise in future larger changes.

test: create some history in test-dirstate-backup An empty repository, based on `null` is quite a corner cases. We create a more "natural" setup for this tests to make sure it can keep testing what it intend to test in the future.

test: explicitly "add" file before some commit in test-keyword.t `hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.

test: explicitly "add" file before some commit in test-filecache.py `hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.

test: explicitly "add" file before some commit in test-bookmark.t `hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.

test: explicitly "add" file before some commit in test-rollback.t `hg commit -A` will revert the `hg addremove` step if the commit fails. However `hg rollback` currently does not. We are about to improve internal consistency around transaction and dirstate and the behavior of `hg rollback` will align on the other behavior in the process. Before doing so, we make sure the test is using a separate call to `hg add` to avoid the test scenario to be affected by that future change. note: the behavior change for `hg rollback` seems fine as it affect a niche usecase and `hg rollback` usage have been strongly discouraged for a while.

rhg-files: add support for narrow when specifying a revision This makes it so that `rhg files -r NODE` works properly when using narrow.

rust-narrow: enable narrow support for plain `rhg files` Support for `rhg files -r NODE` in a future changeset.

rhg-files: make signature of `display_files` more flexible This allows the callers to use any error type that converts to `CommandError` instead of a particular concrete type.

rhg: fix user-facing error message so it matches Python implementation

rust-ui: refactor ui code for printing narrow/sparse warnings This will be used elsewhere in the code, starting from the next commit.

rhg-files: reuse centralized dirstate logic The `files` logic predates the centralized dirstate logic. It was duplicated, an didn't receive bugfixes along the way.

rust: move `filter_map_results` to public util This is a useful general-purpose function. It will be used in the next changesets.

rhg: fix typo

run-tests: stop ignoring venv-installed packages This will allow test dependencies to be installed within a venv, instead of tampering with sys/user sites. One thing to note here is that the `VIRTUAL_ENV` path takes precedence over system-site, unlike when run directly with an activated `venv`. For example, `sys.path` as viewed from a feature test in `hghave.py`, when running `hghave vcr` directly with an activated `venv`: sys.path: [ '/home/jenkins/hg-committed/tests', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/jenkins/test_venv/lib/python3.8/site-packages' ] vs `sys.path` from the same feature test, when run by `run-tests.py` with this change: sys.path: [ '/home/jenkins/hg-committed/tests', '/home/jenkins/hg-committed', '/home/jenkins/hg-committed/tests', '/home/jenkins/test_venv/lib/python3.8/site-packages', '/usr/lib/python38.zip', '/usr/lib/python3.8', '/usr/lib/python3.8/lib-dynload', '/home/jenkins/.local/lib/python3.8/site-packages', '/usr/local/lib/python3.8/dist-packages', '/usr/lib/python3/dist-packages' ]

bundlerepo: raise `error.LookupError` instead of `LookupError` I'm pretty sure that this was the intention, given `error.LookupError` is raised a few lines above with the same arguments. Note that PyCharm complains about `self.display_id` (and the use above this too) being `() -> Any` instead of `bytes`, but it may be confused about the `util.propertycache` annotation on it.

unionrepo: resync several methods to actually override superclass methods Not sure how/when these skewed, but these were flagged by PyCharm as having different signatures.

branching: merge with stable

storageutil: match node length with repository

dirstate: enforce holding the lock while doing any changes This seems like a sensible sanity check. This already caught the issue in largefile. This will catch more issue when we start using similar context manager for operation other than the parent changes.

largefile: make sure we hold the lock when updating the second dirstate The largefile extension uses a second dirstate file (and object) to track some states. In some situations, it is lazily updated when needed. These operations might not have the lock taken. This means they might conflict and race with other ongoing operations. So we now take the lock to do these operations. This was caught by the next commit.

dirstate: rename `@requires_no_parents_change` too This match the rename of the context manager.

dirstate: rename `@requires_parents_change` to `@requires_changing_parents` This match the rename of the context manager.

dirstate: write dirstate on successful exit of changing_parents context This is the first step toward having more sensible and predicatable write patterns for the dirstate. Having better write/rollback patterns will greatly reduce and clarify the needs to backup the dirstate.

dirstate: rename parentchange to changing_parents Since the new argument breaks the API anyway, we can rename it to a better name. The previous name `parentchange` might be seen as something active, a function that would directly change the parents, however this is just a context manager to frame the operation that will change the parents and adjust the dirstate content accordingly. In addition, the future sister method that will be about changes to tracking and files would have a hard time fitting in the same naming scheme in a clear way. The new naming uses a clear prefix will make it more distinct from other dirstate methods and easier to extend with other similar contexts.

dirstate: pass the repo to the `changeparent` method If we want the context to be responsible for writing (and we want it), we need to have access to a localrepository object. So we now requires a localrepository object as an argument to this context manager.

dirstate: warn about non-explicitly rolledback parent-change Now that the invalidation is dealt with by the context manager itself, we should no longer need this in the unlocking code. We start with issuing a warning if this is the case before actually dropping this code later.

dirstate: invalidate changes when parent-change fails When an error occurs during changing parents, we should invalidate all dirstate modifications and reload the dirstate. This is currently done by a `unlock` callback on the `wlock`. To fix this anomaly, we start dealing with the error directly in the context manager and its potential nesting. The "hard" part is to make sure that, when the parent-change context are nested, we and higher level nesting do not continue to use the invalidated dirstate. We introduce dedicated code to enforce that.

setup: Ensure target directory exists with building rust extension When the rust extension is the first to be build, the target directory may not exist so the copy fails.

filemerge: add union-other-first as internal merge tool See inline documentation for details.

rust: use `peek_mut` from the standard lib now that it's stable Just a little cleanup of a TODO found along the way.

clippy: actually fail if there are any warnings So far, only errors would trip the CI, this makes it so all warnings are elevated to errors, making it a CI fail if any warnings are present. This was the intended behavior, I just missed this when adding clippy.

rust-clippy: fix warning about nested ifs

debugshell: allow commands to be specified as a CLI argument Add a `--command` option to `hg debugshell` that allows the user to pass in Python code to evaluate directly from the command line. This was inspired by the `--command` option present in Facebook's Sapling fork of Mercurial, which in turn was inspired by the `-c` option of the Python interpreter itself. It is particularly useful for writing tests, especially for getting visibility into things that otherwise aren't exposed via debug commands.

heptapod-ci: add `clippy` to the CI This linter mostly makes our code more idiomatic, less surprising, has good suggestions and catches bugs. It's widely used in the Rust community and now part of the default toolchain when using `rustup`.

makefile: add `cargo clippy` to tests if cargo is available This linter mostly makes our code more idiomatic, less surprising, has good suggestions and catches bugs. It's widely used in the Rust community and now part of the default toolchain when using `rustup`.

rust-tests: run `cargo` tests inside the `rust` folder There is no reason to only run inside the `rust/hg-cpython` folder, even if the `cargo test --all` behavior ends up being the same.

rust-clippy: merge "revlog" module definition and struct implementation Module inception is confusing when looking for code and almost never the right choice.

rust-clippy: merge "config" module definition and struct implementation Module inception is confusing when looking for code and almost never the right choice.

rust-clippy: upgrade `bytes-cast` dependency I released a new version of `bytes-cast` to get rid of the clippy warning, and bump to edition 2021, so let's use it.

rust-clippy: remove redundant suffix from enum Same as last time, this makes the code clearer in this instance.

rust-clippy: fix remaining warnings in `hg-cpython`

rust-clippy: disable some lints crate-wide for `hg-cpython` `rust-cpython` creates some pretty funky code that also needs to be compatible with pretty old Rust. This makes clippy quite useless in `hg-cpython` unless you disable the lints that are always triggered by `py_class!` and related. Maybe `clippy` will allow one day to exclude a dependency from its linting, but this seems quite unlikely, so this is the best we've got at the moment.

rust-clippy: fix remaining warnings in `rhg` All of these are simple changes that for the most part are clear improvements and the rest are at most equivalent.

rust-clippy: fix most warnings in `hg-core` All of these are simple changes that for the most part are clear improvements and the rest are at most equivalent. The remaining warnings have to be fixed either with a bigger refactor like for the nested "revlog" module, or in the dependency `bytes-cast`, which we own. This will be done sometime in the future.

rust-utils: strip redundant prefix from enum This was highlighted by `clippy`, I think this makes the code cleaner.

rust-filepatterns: don't `Box` subincludes unnecessarily This was caught by `clippy`.

rust-nodemap: implement `PartialEq` without allocation This was caught by `clippy`. It's probable that this ends up optimized out by the compiler, but let's not rely on that.

rust-clippy: tell `clippy` we don't need to declare a default here This is a struct only useful for tests.

rust-clippy: refactor complex type This makes reading the signature a bit less tiring.