tests: bump default timeout to 360s A number of tests hit or almost hit the default limit even on modern hardware. While the tests are ideally split into smaller pieces, that's non-trivial work. HyperThreading and similar technologies can trigger this often, even without any other load on the machine. Differential Revision: https://phab.mercurial-scm.org/D10534

relnotes: copy contents of "next" to "5.8" and clear "next" The same procedure as every year^Wcycle. Unlike previous cycles, I haven't actually recorded the copy because we don't want to propagate further changes in "next" (from the stable branch) to "5.8". Differential Revision: https://phab.mercurial-scm.org/D10500

dirstateguard: use mktemp-like functionality to generate the backup filenames Previously these were generated with names like: `dirstate.backup.commit.<memory address of dirstateguard>` This could cause problems if two hg commands ran at the same time that used the same memory address, (which is apparently not uncommon if chg is involved), as memory addresses are not unique across processes. This issue was reported in the post-review comments on http://phab.mercurial-scm.org/D9952. Differential Revision: https://phab.mercurial-scm.org/D10504

repoview: separate concerns in _filteredrepotypes comment The cited issue in Python bugtracker is closed, but hasn't been fixed. We've been able to use the attached example and reproduce it with Python 3.9. The point where it turns from needless stress on the GC to the an actual leak is when one factors in the fact that the GC was before Python 3.4 unable to collect some types (see PEP 442). Note that even with Python 2.7, the simple example of cycles due to __mro__ are collectable. This was seen again with the example attached on the CPython issue.

repoview: fix memory leak of filtered repo classes The leak occurs in long-running server processes with extensions, and is measured at 110kB per request. Before this change, the contents of the `_filteredrepotypes` cache are not properly garbage collected, despite it begin a `WeakKeyDictionary`. Extensions have a tendency to generate a new repository class for each `localrepo` instantiation. Server processes based on `hgwebdir_mod` will instantiate a new `localrepo` for each HTTP request that involves a repository. As a result, with a testing process that repeatedly opens a repository with several extensions activated (`topic` notably among them), we see a steady increase in resident memory of 110kB per repository instantiation before this change. This is also true, if we call `gc.collect()` at each instantiation, like `hgwebdir_mod` does, or not. The cause of the leak is that the *values* aren't weak references. This change uses `weakref.ref` for the values, and this makes in our measurements the resident size increase drop to 5kB per repository instantiation, with no explicit call of `gc.collect()` at all. There is currently no reason to believe that this remaining leak of 5kB is related to or even due to Mercurial core. We've also seen evidence that `ui.ui` instances weren't properly garbage collected before the change (with the change, they are). This could explain why the figures are relatively high. In theory, the collection of weak references could lead to much more misses in the cache, so we measured the impact on the original case that was motivation for introducing that cache in 7e89bd0cfb86 (see also issue5043): `hg convert` of the mozilla-central repository. The bad news here is that there is a major memory leak there, both with and without the present changeset. There were no more cache misses, and we could see no more memory leak with this change: the resident size after importing roughly 100000 changesets was at 12.4GB before, and 12.5GB after. The small increase is mentioned for completeness only, and we believe that it should be ignored, at least as long as the main leak isn't fixed. At less than 1% of the main leak, even finding out whether it is merely noise would be wasteful. Original context where this was spotted and first mitigated: https://foss.heptapod.net/heptapod/heptapod/-/issues/466 The leak reduction was also obtained in Heptapod inner HTTP server, which amounts to the same as `hgwebdir_mod` for these questions. The measurements done with Python 3.9, similar figures seen with 3.8. More work on our side would be needed to give measurements with 2.7, because of testing server process does not support it.

repoview: style change in newtype() cache handling This way of writing it does not change the logic at all, but is more fit for the change we want to make in the next changeset. If anything, that's one dict lookup less in the hot path, but that should be non measurable.

tests: don't hard-code /bin/bash From Thomas Klausner in pkgsrc. Differential Revision: https://phab.mercurial-scm.org/D10507

lint: fix failing code check 8d2b62d716b0 introduced code that `test-check-code.t` wasn't happy about, this fixes it. Differential Revision: https://phab.mercurial-scm.org/D10506

typing: enable pytype processing on mercurial/upgrade_utils/actions.py This was the suggested workaround for the pytype bug that caused this file to be processed forever. Differential Revision: https://phab.mercurial-scm.org/D10460

incoming: use bytes for an error message Caught by pytype. Differential Revision: https://phab.mercurial-scm.org/D10461

merge: stable heads I forgot to pull before rolling rc1, so we just have a couple of patches that missed the rc1 train. Mea culpa.

Added signature for changeset 8d2b62d716b0

Added tag 5.8rc1 for changeset 8d2b62d716b0

relnote: mention a nodemap bug fixes The fix was in a3720569a43f. Differential Revision: https://phab.mercurial-scm.org/D10499

relnote: document the use of persistent-nodemap by default for Rust build Differential Revision: https://phab.mercurial-scm.org/D10498

relnode: document the move to `zstd` as default compression Differential Revision: https://phab.mercurial-scm.org/D10497

relnote: clarify the backward compatibility entry about p1/p2 swap The previous message might read a bit scary. So we clarify that the nodeid are not affected. Differential Revision: https://phab.mercurial-scm.org/D10496

mail: add a TODO about proper mbox locking Per @nbjoerg in IRC, the mbox isn't locked correctly. Differential Revision: https://phab.mercurial-scm.org/D10505

packaging: extract pre-computed version when running from plain tarball The tarballs created by setup.py are not including the usual archive markers that `hg archive` leaves, so the rewrite of the version number computation actually left the empty version string around. This meant that installations from PyPI would use 0.0.0 as version string. Differential Revision: https://phab.mercurial-scm.org/D10502

Added signature for changeset f67b8946bb1b

Added tag 5.8rc0 for changeset f67b8946bb1b

merge: default into stable for 5.8 rc

mail: force SMTPException to bytes before wrapping in error.Abort Pytype wasn't complaining about this for some reason, but PyCharm was and we already handle another instance of this exception the same way in this function. Differential Revision: https://phab.mercurial-scm.org/D10473

mail: split out the SMTP login to allow the keyring extension to wrap it The keyring extension only needs to tweak this tiny section of the larger function. But without any place to intercept the username/password fetching, it copy/pasted the entire function, and has grown a bunch of compatibility hacks to support older versions of Mercurial as well. Differential Revision: https://phab.mercurial-scm.org/D10471

store: exclude `undo.` nodemap's file from `walk` There are "temporary" local file that we should not be transfered by `walk` user like local clone and stream clone. This fix the small issue that the new tests highlighted. Differential Revision: https://phab.mercurial-scm.org/D10482

streamclone: treat volatile file as "fullfile" The nodemap related file might change (or get deleted) during the stream clone in a way incompatible with the streaming process. So we introduce a new flag for this type of file and integrate it with the existing `revlog_type` field recently added to `store.walk` returns. We use that new flat to dispatch such file to the existing mechanism for "atomic replacement" file for the nodemap docket and datafile. This fix the bugs we have been adding tests for. Strictly speaking, the nodemap datafile is happened only a could maybe be used in a slightly more efficient way, however this is good enough for now. Differential Revision: https://phab.mercurial-scm.org/D10481

nodemap: add a test about nodemap "vacuum" during stream clone When the nodemap "vacuum" it generate a new datafile, with a new unique name and delete the old one. This confuse the stream clone code and create the same kind of crash we were seeing in the previous patch. We build a test case where this happens. The next changeset will contains a fix We can also notice that we are, wrongfully exchanging `undo.*` files that the client will not be able to use. This will be dealt with soon. Differential Revision: https://phab.mercurial-scm.org/D10480

nodemap: add a test about racy commit during stream clone That test show that the resulting client nodemap is different from the server one. This happens because the server one transferred a corrupted node map. The data file match the pre-commit content while the docket has post commit content. As the result the nodemap was detected invalid and recomputed. When running without the rust implementation, the code is also generating a new datafile unconditionally, This mean the older file is no longer there are transfer time, resulting in a crash. We will fix this issue later, but we start with writing tests highlighting the issue. Differential Revision: https://phab.mercurial-scm.org/D10479

streamclone: remove sleep based "synchronisation" in tests Sleep based test synchronisation does not work. Variation in machine performance and load can make the two process miss their windows. Instead we migrate to explicit signaling through the file system as other tests file are using. Differential Revision: https://phab.mercurial-scm.org/D10478

testing: add a `write_file` function The function is kinda trivial, but having a simple function avoid silly mistake. Differential Revision: https://phab.mercurial-scm.org/D10477

testing: add a utility function to wait for file create This is similar to `tests/testlib/wait-on-file`, but for the python code Differential Revision: https://phab.mercurial-scm.org/D10476

streamclone: check the errors log in tests Code can be buggy, in that case having error message tend to help. Differential Revision: https://phab.mercurial-scm.org/D10475

mail: use a context manager when writing to mbox Differential Revision: https://phab.mercurial-scm.org/D10484

errors: remove unnecessary varargs handling from OutOfBandError In my recent D10465, I moved some code over from scmutil into `OutOfBandError.__init__`. The code was written to deal with an arbitrary number of `message` arguments to the constructor. It turns out that we only ever pass 0 or 1. Given that, let's simplify it. Differential Revision: https://phab.mercurial-scm.org/D10483

phab-refresh: use a special comment on the stable branch Phabricator make it hard to spot the branch information. As a result patch intended for stable are consistently queued for default. We add a special command and flashy GIF to try to attract reviewer attention on the fact patch are intended for stable. Differential Revision: https://phab.mercurial-scm.org/D10464

phab-refresh: extract the comment in a variable This make the script more readable and it is about to become more complex. Differential Revision: https://phab.mercurial-scm.org/D10463

tests: make test-archive.t pass on py3.9 (issue6504) Something got stricter at parsing URL query parameters and now the parameters need to be separated by "&"; ";" is no longer allowed. See issue6504 for details. Differential Revision: https://phab.mercurial-scm.org/D10472

errors: raise RemoteError in some places in exchange.py This is part of https://www.mercurial-scm.org/wiki/ErrorCategoriesPlan Differential Revision: https://phab.mercurial-scm.org/D10467

errors: introduce a class for remote errors Having an exception for remote errors makes it much easier to exit with the right detailed exit code. Differential Revision: https://phab.mercurial-scm.org/D10466

errors: make OutOfBandError extend Abort I'm about to create a new `RemoteError` exception and make `OutOfBandError` extend it. This patch prepares for that. Differential Revision: https://phab.mercurial-scm.org/D10465

revlog: replace revlog._io.size with a new revlog.index.entry_size The `revlogio` class is mostly a relic from the past. Once in charge of the full revlog related Input/Output code, that class gradually lost responsibilities to the point where more IO are now done by `revlog.index` objects or revlog objects themself. I would like to ultimately remove the `revlogio` class, to do so I start simple with move the "entry size" information on the index. (The index is already responsible of the binary unpacking, so it knows the size. Differential Revision: https://phab.mercurial-scm.org/D10309

perf-discovery: use `get_unique_pull_path` This performance command now use the new API, unless the benchmarked Mercurial is older. Differential Revision: https://phab.mercurial-scm.org/D10423

help: clarify when `$HG_URL` and `$HG_SOURCE` are added in hooks Differential Revision: https://phab.mercurial-scm.org/D10400

nodemap: deal with data mmap error If the file is too small, the mmapread call would raise a ValueError. We catch that and ignore nodemap content (as we do without mmap). This make the repository slightly slower (until the next write) but usable. Unlike the current crash. Differential Revision: https://phab.mercurial-scm.org/D10458

nodemap: test various corruption scenario for the persistent nodemap Corruption can happens in the wild, either because some of our code is buggy or because repository were shared/transfered in a strange manners. Currently one of the corruption case (not enough data) lead to a crash. We add explicit tests for theses cases. Differential Revision: https://phab.mercurial-scm.org/D10457

cmdutil: fix an uninitialize variable usage in clearunfinished() I happened to notice that PyCharm flagged this while looking for something else. I'm pretty sure it meant to check the current state in the iteration, and not keep reusing the last one in the previous iteration. Differential Revision: https://phab.mercurial-scm.org/D10459

help: document `$HG_NEW_OBSMARKERS` in pretxnclose hook Differential Revision: https://phab.mercurial-scm.org/D10399

help: prepend environment variables used in hooks with "$" Most of them have "$" prefix but some don't, so adding it for consistency. Differential Revision: https://phab.mercurial-scm.org/D10398

revset: drop an outdated comment There is not `ui.expandpath` call there anymore. Differential Revision: https://phab.mercurial-scm.org/D10435

ui: deprecated `ui.expandpath` This function return a single path, something incompatible with the coming change to `[paths]` definition to allow multiple associated urls. Now that all user got migrated, we deprecate the function. Differential Revision: https://phab.mercurial-scm.org/D10432

urlutil: remove usage of `ui.expandpath` in `get_clone_path` We want to deprecate `ui.expandpath` and simplify the code before adding more complexity in the form of `[paths]` entry pointing to multiple url. So we inline the relevant bits. Differential Revision: https://phab.mercurial-scm.org/D10431

urlutil: remove usage of `ui.expandpath` in `get_unique_pull_path` We want to deprecate `ui.expandpath` and simplify the code before adding more complexity in the form of `[paths]` entry pointing to multiple url. So we inline the relevant bits. Differential Revision: https://phab.mercurial-scm.org/D10430

urlutil: remove usage of `ui.expandpath` in `get_pull_paths` We want to deprecate `ui.expandpath` and simplify the code before adding more complexity in the form of `[paths]` entry pointing to multiple url. So we inline the relevant bits. Differential Revision: https://phab.mercurial-scm.org/D10429

debugbackupbundle: use `get_unique_pull_path` This is the last known user of `ui.expandpath` outside of `urlutil`. Hooray. Differential Revision: https://phab.mercurial-scm.org/D10428

debugssl: use `get_unique_pull_path` Let's move this code to the new API. Differential Revision: https://phab.mercurial-scm.org/D10427

debugdiscovery: use `get_unique_pull_path` Lets move this code to the new API. Differential Revision: https://phab.mercurial-scm.org/D10426

profiling: use `util.expandpath` instead of `ui.expandpath` for output Given we are talking about the path to an output file, I am fairly certain that the initial author meant to expand `~` and the like and not to resolve entry from `[paths]`. Differential Revision: https://phab.mercurial-scm.org/D10425

dispatch: use the new API to resolve --repository An even weirder feature of Mercurial is the ability to use `[paths]` alias as value of `--repository`. The weird feature now use the new APIs. Differential Revision: https://phab.mercurial-scm.org/D10424

revset: use `get_unique_pull_path` for `remote(…)` This one is also resolving path. For now we restrict the feature to a single destination. This might change in the future. Differential Revision: https://phab.mercurial-scm.org/D10422

remotefilelog: use `get_unique_pull_path` in `getflogheads` Another command moved to the new API, hooray. Differential Revision: https://phab.mercurial-scm.org/D10421

summary: use the new APIs Summary can perform some incoming/outgoing queries (that should be common to the other command with the same needs, but that is another story). We now use the new APIs to do so. The current code behavior is a bit fishy, relying to the fact "default" will be picked as the destination in last resort. I did not altered that, but left various comment to highlight the issue. Differential Revision: https://phab.mercurial-scm.org/D10420

share: use `get_clone_path` Since `hg share` is mostly like clone, do the same changes there. Differential Revision: https://phab.mercurial-scm.org/D10419

init: use `get_clone_path` when suitable `hg init` has this weird feature were you can refer to `[paths]` entry select the path to initialize. We move that code to the new APIs. Differential Revision: https://phab.mercurial-scm.org/D10418

clone: use `get_clone_path` "Surprisingly", the new API is well suited for `hg clone` too. Differential Revision: https://phab.mercurial-scm.org/D10417

incoming: kill the `repo._subtoppath =` hack We do the same as for `hg outgoing`, instead of relying on implicit passing value by monkey punching them onto the repo object, we pass equivalent information by argument to the proper function. This is way cleaner. Differential Revision: https://phab.mercurial-scm.org/D10416

identify: use `get_unique_pull_path` The command only support a single destination. We use the associated API. Differential Revision: https://phab.mercurial-scm.org/D10415

bundle: support multiple destinations `hg outgoing` and `hg push` now support multiple destination. We do the same for `hg bundle`. Various other commands needs this kind of behavior and it would be create to factor this code out for their usage. However this is an adventure for another time. They are some minor change to the tests (in addition to the new test for the feature): * one because I updated a message to plurals, * another one because the error changed, and I actually find it clearer. Differential Revision: https://phab.mercurial-scm.org/D10414

lfs: use the new APIs The part of the lfs store that requires a destination cannot operate on multiple destination (yet). So we move them to the dedicated APIs. Differential Revision: https://phab.mercurial-scm.org/D10413

fastannotate: use `get_unique_pull_path` The code does not support multiple destination yet, so lets move it to the dedicated API. Differential Revision: https://phab.mercurial-scm.org/D10412

remotefilelog: use the right expandpath in to expand `~` Given the context where path is most likely a file system path, I suspect that the initial author confused ui.expandpath and util.expandpath (a proxy for os.path.expanduser and co) Differential Revision: https://phab.mercurial-scm.org/D10411

transplant: use `get_unique_pull_path` The command does not support multiple destination (yet). Differential Revision: https://phab.mercurial-scm.org/D10410

infinitepush: use `get_unique_pull_path` The extension does not support multiple destination (yet). Differential Revision: https://phab.mercurial-scm.org/D10456

relink: use `get_unique_pull_path` The code does not support multiple destination and will probably never do so. So lets use the dedicated API for this case. Differential Revision: https://phab.mercurial-scm.org/D10409

histedit: use `get_unique_push_path` Same as for `pathbomb`, this code does not support multiple destinations yet. It might in the future, probably with code put in common with patchwork, but for now lets use the dedicated API. Differential Revision: https://phab.mercurial-scm.org/D10408

urlutil: add a new `get_unique_push_path` This function is dedicated to call that needs a single destination. Currently most caller actually need that since few actually support multiple destinations (the most importants `hg push` and `hg outgoing` do). So having a clear API point for that will be important when the time comes to have a single `[paths]` alias resolving to multiple urls. Differential Revision: https://phab.mercurial-scm.org/D10407

fetch: use `get_unique_pull_path` to retrieve the path The fetch command does not support multiple destination, so we use the new dedicated API for that. Differential Revision: https://phab.mercurial-scm.org/D10406

patchbomb: use `get_unique_pull_path` The patchbomb code does not support multiple destinations yet. It would not be too hard to implemented since `hg outgoing` does. However that is a bit too much of a detour right now. In addition that kind of "select outgoing changesets for processing" code exist for various commands so the best would be to factor it out later. Let us use the dedicated API until this is solved. This comes with a small output change in the test that I find more accurate. So I kept it. Differential Revision: https://phab.mercurial-scm.org/D10405

narrow: use `get_unique_pull_path` The narrow's `tracked` command does not support multiple destination, lets use the dedicated API then. Differential Revision: https://phab.mercurial-scm.org/D10404

urlutil: add a new `get_unique_pull_path` This function is dedicated to call that needs a single destination. Currently most caller actually need that since few actually support multiple destinations (the most importants `hg push` and `hg outgoing` do). So having a clear API point for that will be important when the time comes to have a single `[paths]` alias resolving to multiple urls. Differential Revision: https://phab.mercurial-scm.org/D10403

mq: use the new `get_clone_path` to get the remote url We stop using `ui.expandpath` to use a function with a more defined semantic. This will help us to make it an option to point [paths] entry to multiple destination. Differential Revision: https://phab.mercurial-scm.org/D10402

urlutil: add a `get_clone_path` function We add a new function with a semantic focussed on `clone` operation (so without an existing repository). I am not certain the return type is the best, but this is what we need for now. Once all caller are migrated we might start thinking about that the API should be. For now that will do. Differential Revision: https://phab.mercurial-scm.org/D10401

outgoing: use `get_push_paths` in the revset too The revsets now use the same code as everyone and is ready for entry in `[paths]` pointing to multiple entries. Differential Revision: https://phab.mercurial-scm.org/D10393

incoming: use `urlutil.get_pull_paths` Lets use the new method to increase code reuse. However I did not implement support for multiple source yet. It would be possible create multiple temporary bundle, but that is a bit too much work outside of my current route to make the detour. Differential Revision: https://phab.mercurial-scm.org/D10392

outgoing: accept multiple destinations This align the behavior of `hg outgoing` with the one of `hg incoming`. In addition this prepare the introduction of having simple `path` resolve to multiple destination in practice (eg: `default`) Differential Revision: https://phab.mercurial-scm.org/D10391

outgoing: pass subrepo path using function argument instead of abssource hack This is clearer, remove the needs for the `repo._subtoppath` hack and will make our live easier when making `outgoing` accept multiple destinations. Differential Revision: https://phab.mercurial-scm.org/D10390

subrepo: introduce a `repo_rel_or_abs_source` function The `subrepoutil` module has various function to compute the path of a sub-repository compared to the root of the top repository. However, they was no function available to compute the relative path of the repository "source". And we need this information for exchange operation (in our case, `hg outgoing`). The information is currently build using the `repo._subtoppath` hack. We reuse the same logic but in a dedicated function independent of the `repo._subtoppath` hack. Differential Revision: https://phab.mercurial-scm.org/D10434

urlutil: use bytes for Abort messages Caught by pytype. Also fix a minor grammar issue in the second message. Differential Revision: https://phab.mercurial-scm.org/D10433

changegroup: update comment Gratuitous fix, I stumbled upon this comment while reading code. Differential Revision: https://phab.mercurial-scm.org/D10339

re2: adjust local variable assignment scope Pytype flagged the exception handler where these are used as `[name-error]`, and PyCharm complained they may be used before assignment. Differential Revision: https://phab.mercurial-scm.org/D10376

rhg: Make `files` work on repo-relative paths when possible When the current directory is outside of the repository we need to turn everything into absolute filesystem paths in order to compute correct relative paths. This was previously done unconditionally, but is not necessary when the current directory is inside the repository. With this change `rhg files > /dev/null` at the root of a mozilla-central snapshot goes from ~150 ms to ~70 ms. My repository is located at a somewhat long path though (93 bytes). The effect may not be as pronounced at a shorter path. Differential Revision: https://phab.mercurial-scm.org/D10200

split: avoid strip if split is a no-op (identical to original) Differential Revision: https://phab.mercurial-scm.org/D10389

split: fix issue with empty splits adjusting phases Differential Revision: https://phab.mercurial-scm.org/D10388

split: add test demonstrating issue with empty splits adjusting phases Differential Revision: https://phab.mercurial-scm.org/D10387

test-lfs: fix expected output This is not covered by the CI and was broken. Differential Revision: https://phab.mercurial-scm.org/D10397

test-lfs: avoid a bashism when spawning the server For zsh, this &> call is read as "& >", this spin the process without redirection. As a result the server grab stdout, which does not get closed at the end of the test. As a result `run-tests.py` hang there forever, waiting for the the stream for be close. (which is probably as issue on its own). Differential Revision: https://phab.mercurial-scm.org/D10396

test-lfs: avoid pagination Otherwise, the pagination can trigger in when running the test with --debug, blocking the test execution for no good reason. Differential Revision: https://phab.mercurial-scm.org/D10395

run-test: make it clearer why we terminating process The --verbose log wer only talking about process termination. Now we have more information about why. Differential Revision: https://phab.mercurial-scm.org/D10394

push-dests: move the code around missing default dest inside `get_push_paths` This function has a clear semantic and moving the code dealing with this inside it will help reduce duplication. Differential Revision: https://phab.mercurial-scm.org/D10385

push-dests: rework the handling of default value This new core is more straightforward and doing this early will make the next changeset simpler. Differential Revision: https://phab.mercurial-scm.org/D10384

outgoing: merge the code handling --graph with the main one The --graph code had its own copy of the logic. With the previous reorganisation of the code, we can now merge it with the main code, reducing fragile complication. As a side effect, `hg out --graph` now use the right return code when they are nothing outgoing. This explain the change to output in `tests/test-largefiles-misc.t`. Differential Revision: https://phab.mercurial-scm.org/D10383

outgoing: move filtering logic in its own function This move code dedicated to a single purpose together and make the main code simpler. Right when we are getting ready to make it more complex :-D Differential Revision: https://phab.mercurial-scm.org/D10382

outgoing: make `recurse` a real function If we want to use this in a loop, we need to be able to pass argument. Differential Revision: https://phab.mercurial-scm.org/D10381

outgoing: remove some early return Since 066b8d8f75b8, the push command accept multiple destination. However `hg outgoing` does not. On the way to fix this, we need to clean up the outgoing code. We start with removing some early return to make the code ready to house more changes. Differential Revision: https://phab.mercurial-scm.org/D10380

infinitepush: use the new function to determine push destination Since 066b8d8f75b8, the push command accept multiple destination. `infinitepush` was not aware of that. We now use the new `urlutil.get_push_paths` function to determine the push destination, fixing the issue. This will also make future evolution of that logic transparent for infinitepush We still disallow push to multiple destinations if infinite push is enabled because I don't know what this means for infinite push. However user will now get a clear error message instead of a crash. Differential Revision: https://phab.mercurial-scm.org/D10379

urlutil: add a `get_pull_paths` to perform the pull destination logic As is this changeset does not change anything. However having an official empty point will help unifying the logic and encapsulate the details and update the logic to support path definition pointing to multiple other path. Differential Revision: https://phab.mercurial-scm.org/D10378

urlutil: add a `get_push_paths` to perform the push destination logic As is this changeset does not change anything. However having an official empty point will help unifying the logic and encapsulate the details and update the logic to support path definition pointing to multiple other path. Differential Revision: https://phab.mercurial-scm.org/D10377

urlutil: extract `parseurl` from `hg` into the new module The new module is well fitting for this new code. And this will be useful to make the gathered code collaborate more later. Differential Revision: https://phab.mercurial-scm.org/D10375

urlutil: extract `url` related code from `util` into the new module The new module is well fitting for this new code. And this will be useful to make the gathered code collaborate more later. Differential Revision: https://phab.mercurial-scm.org/D10374

urlutil: extract `path` related code into a new module They are a lot of code related to url and path handling scattering into various large module. To consolidate the code before doing more change (for defining "multi-path"), we gather it together. Differential Revision: https://phab.mercurial-scm.org/D10373

help: document the `path://` url scheme If we want people to use it, we need to document it. Differential Revision: https://phab.mercurial-scm.org/D10372

help: point to `hg help urls` in `hg help config.paths` This seems useful to point at what people can put as value for these config. Differential Revision: https://phab.mercurial-scm.org/D10371

merge with stable

narrow: add capabilities for local repos, not just remote peers This fixes the bug where running `hg clone --narrow ./local-repo` fails with abort: server does not support narrow clones even when the server has narrow enabled. Differential Revision: https://phab.mercurial-scm.org/D10357

typing: make minor adjustments to mercurial/util.py to pass pytype checking I'm assuming the wrong-arg-count is a pytype bug, because this code is used by the config object. Avoiding initializing `_lrucachenode` node points to None eliminates a few `is not None` assertions, but apparently not all of them. I can't figure out why it gets confused over the state where these new assertions are. Differential Revision: https://phab.mercurial-scm.org/D10276

util: fix the signature for the pypy override of sortdict.update() PyCharm flagged this as not matching the base class signature. Not sure if there was anything supplying these extra arguments though. Differential Revision: https://phab.mercurial-scm.org/D10275

typing: add type hints to mercurial/error.py The only slightly unusual things here are that `location` is passed to `ParseError` and both bytes and an int (so this accepts both), and the message passed `ProgrammingError` is immediately converted to str. Therefore it is typed as `AnyStr`, because there are a couple of instances that are already passed as str. There are a couple of places where bytes are being passed to builtin exceptions that might need to be converted to str. Differential Revision: https://phab.mercurial-scm.org/D10274

tests: add a (very slow) test that executes pytype This is an updated form of D7295, and completes successfully with pytype 2021.03.22. The 5 or so crashes that were mostly in the hgweb files seems to have been fixed in 2021.03.10. Differential Revision: https://phab.mercurial-scm.org/D10237

upgrade: do not hardcore file extension of revlogs This logic already lives inside the `store` module. So lets reuse it instead. Differential Revision: https://phab.mercurial-scm.org/D10317

upgrade: take advantage of the new information returned by `store.walk` Before this change the upgrade code had to analyse filename to process them directly. Lets keep that logic private to the store and more to a more robust explicit approach. Differential Revision: https://phab.mercurial-scm.org/D10316

store: also return some information about the type of file `walk` found We start returning of 4th information in the `store.walk` return tuple: the type of the file. This will make it easier for caller to determine which kind of file they are looking at. This should especically help with the `upgrade-repo` code that has to do a lot of fragile index's file name comparison. Differential Revision: https://phab.mercurial-scm.org/D10315