engine: unwrap a hard to understand for loop The loop was iterating over all the datafiles and maintaining a set to check whether filelogs have been processed, manifests have been processed or not. The code was hard to understand and it assumed that `alldatafiles` are ordered in a certain way. This refactors the for loop in separate parts for each manifests, changelog and filelogs. This will also help in future work where we will like more better handling on whether we want to upgrade filelogs or not. Differential Revision: https://phab.mercurial-scm.org/D9580

engine: refactor actual cloning code into separate function The `for ...` under which this cloning code exists is too complicated and based on certain assumptions. I am going to refactor it in next patches and make it bit saner. Differential Revision: https://phab.mercurial-scm.org/D9579

upgrade: move printing of unused optimizations to UpgradeOperation class Differential Revision: https://phab.mercurial-scm.org/D9578

upgrade: move `printrequirements()` to UpgradeOperation class Part of refactor where we make things more arranged and integrated into single `UpgradeOperation` class. Differential Revision: https://phab.mercurial-scm.org/D9577

upgrade: move `printoptimisations() to UpgradeOperation class Part of refactor where we make things more arranged and integrated into single `UpgradeOperation` class. Differential Revision: https://phab.mercurial-scm.org/D9576

upgrade: move `printupgradeactions()` to UpgradeOperation class Part of refactor where we make things more arranged and integrated into single `UpgradeOperation` class. Differential Revision: https://phab.mercurial-scm.org/D9575

upgrade: move `print_affected_revlogs()` to UpgradeOperation class Part of refactor where we make things more arranged and integrated into single `UpgradeOperation` class. Differential Revision: https://phab.mercurial-scm.org/D9574

hg-core: add basic config module The config module exposes a `Config` struct, unused for now. It only reads the config file local to the repository, but handles all valid patterns and includes/unsets. It is structured in layers instead of erasing by reverse order of precedence, allowing us to transparently know more about the config for debugging purposes, and potentially other things I haven't thought about yet. This change also introduces `format_bytes!` to `hg-core`. Differential Revision: https://phab.mercurial-scm.org/D9408

copies-tests: update to null in test-copies-chain-merge.t This avoid some unrelated output changeset when adding more cases. Differential Revision: https://phab.mercurial-scm.org/D9589

copies-tests: add a summary of all cases created in test-copies-chain-merge.t This helps to keep track of existing branch when adding new cases. Differential Revision: https://phab.mercurial-scm.org/D9588

copies: stop attempt to avoid extra dict copies around branching In the python code, we attempt to avoid unnecessary dict copies when gathering copy information. However that logic is wobbly and I keep running into case where independent branches affects each others. With the current code we can't ensure we are the only "user" of dict when dealing with merge. This caused havoc in the next series on tests I am about to introduce. So for now I am disabling the faulty optimisation. I believe we will need a dedicated overlay to deal with the "copy on write logic" to have something correct. I am also hoping to find time to build dedicated test case for this category of problem instead of relying on side effect in other tests. However for now I am focussing on another issue. Differential Revision: https://phab.mercurial-scm.org/D9608

copies: deal with the "same revision" special case earlier This can happens a lot in case of deletion so we better deal with it early. Differential Revision: https://phab.mercurial-scm.org/D9592

tags: describe all abnormal tag types in `hg tags -v` In particular, this affects `git` and `git-remote` tags when using hg-git. Test Plan: I have not included an explicit test, as this is much more easily tested within the `hg-git` test suite. Differential Revision: https://phab.mercurial-scm.org/D9639

hg-core: add format-bytes dependency This will be used in the next patch to make error messages that require bytestring concatenation clearer. Differential Revision: https://phab.mercurial-scm.org/D9409

rebase: handle the case when nothing to rebase (dry-run) In dry-run mode, even when there was no rebase in progress it tried to abort (for context, at the end of dry-run mode we abort the in-memory performed rebase) because we were not early checking if there was any rebase started. Changes in test file reflect the fixed behavior. Differential Revision: https://phab.mercurial-scm.org/D9659

rebase: add test to demonstrate an issue in dry-run In dry-run mode, the case when there is nothing to rebase is not handled correctly. Added test show that it try to abort a rebase while there is no rebase in progress. This will be fixed in next patch. Differential Revision: https://phab.mercurial-scm.org/D9658

pycompat: fix typos Differential Revision: https://phab.mercurial-scm.org/D9662

chg: format code by clang-format version 11.0.1-+rc1-1 test-check-clang-format.t started failing on my Debian sid environment, and new style looks slightly better. So let's bump the required clang-format version to 11.

test-check-interface: do not expect bare "python" executable exists The test would crash if python executable had version suffix.

procutil: assign pseudo file object if sys.stdout/stderr is missing This basically simulates the Python 2 behavior. If libc stdio were used, these file objects would be available and raise EBADF. There is subtle difference between py2 and py3, but I think py3 behavior (i.e. exit 255) is more correct. "if" conditions are adjust so that they look similar to dispatch.initstdio().

procutil: introduce pseudo file object that just raises EBADF This should be safer than closing underlying fd as the fd may be reused. On Python 2, closed sys.stdin could be redirected to a random file having fd=0, but we'd be better not copying this behavior. Only readinto() and write() are implemented according to the following ABC table. fileno() is not implemented since fd=0/1/2 may be assigned later to other files. https://docs.python.org/3/library/io.html#class-hierarchy

dispatch: gate against missing stdout/stderr We do need procutil.stdin/stdout/stderr, but we don't care much for sys.std*. Let's leave them be None as it is the Python 3 way.

dispatch: remove stale comment about fdopen()-ed stdio On Python 3, stdout is just wrapped by LineBufferedWrapper.

mergetools: add BeyondCompare 4 for Windows This is a copy of the TortoiseHg configuration, but dropping the 3-way diff and dirdiff settings (since those aren't supported in core Mercurial), and swapping the 'parent1', 'parent2', and 'base' literals for `$labellocal`, `$labelother, and `$labelbase` respectively. (That functionality was apparently never ported to TortoiseHg.) Additionally, the single quotes were removed from around these arguments, since none of the other configs have them. Differential Revision: https://phab.mercurial-scm.org/D9635

mergetools: add support for 32-bit BeyondCompare 3 on 64-bit Windows Again, marginal usefulness, but other tools have this config and it eliminates a diff from the TortoiseHg file. Differential Revision: https://phab.mercurial-scm.org/D9634

mergetools: enable the `checkconflicts` option for Araxis Merge This must have been a typo. This matches the config read in filemerge, as well as the TortoiseHg config file. Differential Revision: https://phab.mercurial-scm.org/D9633

mergetools: sync up comments with the TortoiseHg copy of the config file It's of limited value, but a step towards making the diff between the two less noisy. Differential Revision: https://phab.mercurial-scm.org/D9632

rust: introduce Repo and Vfs types for filesystem abstraction This is similar to the corresponding Python classes. Repo represents a repository and knows the path to the `.hg` directory, the `store` directory, and the working directory. Separating these will enable supporting the share extension. A Vfs is created from a Repo for one of these three directories. It has filesystem access APIs that take a relative std::path::Path as a parameter. Differential Revision: https://phab.mercurial-scm.org/D9596