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

fix: add more information to the debug output The previous debug output did not help to understand which file where fixed in which revision. The new output should cover that.

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.

hgweb: unbyteify the 100-continue check The environment seems to be `str` or `tuple[int]`, and the same check in `wsgicgi.py` is already `str` based, so I suspect this was wrong. I think what happened here is that the string wasn't `r''` prefixed in 482d6f6dba91 like `wsgicgi.py`, so it got wrongly byteified in 687b865b95ad when converting to byte literals en masse.

branching: merge with stable

setup: treat error output and non-zero return code differently Choking on Mercurial's stderr mean armless warning can derails the whole install process. We do like to be able to issue warning to people so we stop considering any stderr is a fatal mistake. This allow us to actually boostrap a version of Mercurial without loosing to many sanity point. For example in case where evolve is not loaded, something that happens when the recorded version is malformatted. Creating a wonderful ouroboros.

setup: make the version computation process more resistant The tag fetching might return and empty string¹, from there everything derails quickly. As setup tools becomes more picky about version format we make the whole seems a bit more robust. The resulting version will be obviously weird, but at least it will actually install itself. [1] This is a problem we will address in the next changesets.

bundlerepo: enforce the requirements declared by the underlying repository Previously, `hg log -r 'bundle()' -R bundle.hg` was failing for me when run from source, complaining about an unknown parent, when the system installed `hg` didn't. Some debugging showed the index was 0 length. It turned out that I didn't have the C extensions compiled, which a simple `hg log -r .` was able to indicate. The problem being that the RequirementError got handled by RepoError, which uses an empty directory as a fallback to process the bundle.

scmutil: make checknewlabel() allow "_" in otherwise numeric names (issue6737)

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.