rhg: Ignore trailing newlines in .hg/sharedpath Differential Revision: https://phab.mercurial-scm.org/D10132

tests: Add `--rhg` and `--with-rhg=<path>` options for `run-tests.py` They are mostly equivalent to the corresponding `chg` options. For now, many tests are still failing in this configuration. It is *not* run on CI. Differential Revision: https://phab.mercurial-scm.org/D10095

rhg: Add support for automatic fallback to Python `rhg` is a command-line application that can do a small subset of what `hg` can. It is written entirely in Rust, which avoids the cost of starting a Python interpreter and importing many Python modules. In a script that runs many `hg` commands, this cost can add up. However making users decide when to use `rhg` instead of `hg` is not practical as we want the subset of supported functionality to grow over time. Instead we introduce "fallback" behavior where, when `rhg` encounters something (a sub-command, a repository format, …) that is not implemented in Rust-only, it does nothing but silently start a subprocess of Python-based `hg` running the same command. That way `rhg` becomes a drop-in replacement for `hg` that sometimes goes faster. Whether Python is used should be an implementation detail not apparent to users (other than through speed). A new `fallback` value is added to the previously introduced `rhg.on-unsupported` configuration key. When in this mode, the new `rhg.fallback-executable` config is determine what command to use to run a Python-based `hg`. The previous `rhg.on-unsupported = abort-silent` configuration was designed to let a wrapper script call `rhg` and then fall back to `hg` based on the exit code. This is still available, but having fallback behavior built-in in rhg might be easier for users instead of leaving that script "as an exercise for the reader". Using a subprocess like this is not idea, especially when `rhg` is to be installed in `$PATH` as `hg`, since the other `hg.py` executable needs to still be available… somewhere. Eventually this could be replaced by using PyOxidizer to a have a single executable that embeds a Python interpreter, but only starts it when needed. Differential Revision: https://phab.mercurial-scm.org/D10093

rhg: Add a `rhg.on-unsupported` configuration key For now the two values are: * `abort-silent`: silently exit with code 252, the previous default behavior * `abort`: print an error message about what feature is not supported, then exit with code 252. Now the default. Differential Revision: https://phab.mercurial-scm.org/D10091

rhg: Make configuration available as early as possible in main() Differential Revision: https://phab.mercurial-scm.org/D10090

rust: Upgrade Cargo.lock to the newer format As discussed in https://phab.mercurial-scm.org/D10085#153099 See https://github.com/rust-lang/cargo/pull/7070 and https://blog.rust-lang.org/2020/01/30/Rust-1.41.0.html#less-conflict-prone-cargolock-format Differential Revision: https://phab.mercurial-scm.org/D10089

sshpeer: enable+fix warning about sshpeers not being closed explicitly I recommend looking at this with a diff that ignores indentation. The test changes are because localrepo.close() updates some cache, which appears happens earlier now on rollbacks or strips or something. The http changes are because httppeer.close() prints stats with --verbose. Differential Revision: https://phab.mercurial-scm.org/D9999

sshpeer: add a develwarning if an sshpeer is not closed explicitly The warning is disabled until the next commit, because fixing it results in a noisy diff due to indentation changes. Differential Revision: https://phab.mercurial-scm.org/D9998

remotefilelog: rework workaround for sshpeer deadlocks The wrapping of `sshpeer.cleanup` silently broke when `cleanup` was renamed to `_cleanup`, a couple of years ago. I don't know what `orig.im_self` is, but regardless, the intention of the wrapping seems pretty clear: close stderr before sshpeer._cleanuppipes blocks on it. So do that. Differential Revision: https://phab.mercurial-scm.org/D9997

sshpeer: add a method to check if a doublepipe is closed So we can tell in a next commit if we're trying to close an already closed connection or not (in which case, we may warn). Differential Revision: https://phab.mercurial-scm.org/D9996

sshpeer: make sshpeer.close() close the underlying connection So the connection can be closed eagerly in future commits, instead of relying on __del__. Differential Revision: https://phab.mercurial-scm.org/D9995

copies-rust: add a macro-based unit-testing framework `compare_values`, `merge_copies_dict`, and `CombineChangesetCopies` are APIs whose signatures involve non-trivial types. Calling them directly in unit tests would involve a lot of verbose setup code that obscures the meaningful parts of a given test case. This adds a macro-based test-harness with pseudo-syntax to tersely create arguments and expected return values in the correct types. For now there is only one (not particularly meaningful) test case per tested function, just to exercize the macros. Differential Revision: https://phab.mercurial-scm.org/D10071

copies-rust: rewrite ChangedFiles binary parsing by using the new from-bytes-safe crate and a custom struct that encodes the expected data structure. Differential Revision: https://phab.mercurial-scm.org/D10068

tags: validate nodes in _getfnodes() and update cache in case of unknown nodes `hgtagsfnodescache` can contain unknown nodes due to cache corruption and this lead to a traceback on operations like `hg tags` as we don't validate nodes. This patch validates that all filenodes returned after `hgtagsfnodescache` are known to the repository. If there exists any unknown filenode, we force recompute it and update the cache. The test change demonstrates the fix. Differential Revision: https://phab.mercurial-scm.org/D10083

debugtagscache: verify that filenode is correct Previous patch from Matt demonstrates that `debugtagscache` does not warn about filenode being unknown which can be caused by a corrupted cache. We start by showing that it's an unknown node. Differential Revision: https://phab.mercurial-scm.org/D10015

tests: demonstrate a case where a corrupt tag cache causes an abort I happened to hit this trying to cover other cases around valid vs missing entries. I have no idea if this is something that could occur more naturally (similar to how a missing file node in `hgtagsfnodes1` can occur after a strip). There is a test just above this added in f5a7cf0adb12 mentioning it "overwrites the junk", though that tests truncation instead of actual garbage. But since this is just a cache, it probably shouldn't abort with a cryptic message like this. The two options I see both have downsides- either rebuild the cache (and potentially take a long time), or hint to the user to run a debug command. Differential Revision: https://phab.mercurial-scm.org/D9812

debugcommands: prevent using `is False` I was touching this code in a future patch and marmoute warned about usage of `is False` here. Quoting marmoute: ``` "is False" is going to check if the object you have the very same object in memory than the one Python allocated for False (in practice 0) This will "mostly work" on cpython because of implementation details, but is semantically wrong and can start breaking unexpectedly ``` Differential Revision: https://phab.mercurial-scm.org/D10014

hgtagsfnodes: refactor code to compute fnode into separate fn I plan to use this code at one more place while fixing a bug caused by an invalid fnode present in cache. Differential Revision: https://phab.mercurial-scm.org/D10013

error: remove shortening of node in error message This strips the complete 20 bytes node which was not found. Having the the full node in error message is important as it makes debugging easier. If a short node is to be displayed, that should be done by callers. Differential Revision: https://phab.mercurial-scm.org/D9994

copies: filter out copies grafted from another branch Consider this simple history: ``` @ 3 modify y | o 2 copy x to y, modify x | | o 1 copy x to y, modify x |/ o 0 add x ``` If we now rebase commit 3 onto 1, Mercurial will look for copies between commit 2 and commit 1. It does that by going backwards from 2 to 0 and then forwards from 0 to 1. It will find that x was copied to y, since that was what happened on the path between them (namely in commit 1). That leads Mercurial to do a 3-way merge between y@3 and y@1 with x@2 as base. We want to use y@2 as base instead. That's also what happened until commit 1d6d1a15. This patch fixes the regression by adding another filtering step when chaining copies via a diffbase. The new filtering step removes copies that were the same between the two branches (same source and destination, but not necessarily the same contents). Differential Revision: https://phab.mercurial-scm.org/D10120

copies: inline _backwardrenames() in pathcopies() I'll add another filtering step in `patchcopies()` next. I need access to the forward copies for that. Differential Revision: https://phab.mercurial-scm.org/D10119

copies: extract function _backwardcopies() for reversing renames I'll add another callers in the next patch. Differential Revision: https://phab.mercurial-scm.org/D10118

tests: demonstrate how grafted copies are counted when tracing across branches This test demonstrates a regression from 1d6d1a15. Differential Revision: https://phab.mercurial-scm.org/D10117

typing: add some type annotations to mercurial/pathutil.py Differential Revision: https://phab.mercurial-scm.org/D10128