lfs: fix a discrepancy with a function wanting a filelog, but calling it rlog This conceptually broke in 1541e1a8e87d when the filelog isa revlog relationship was changed to containment of the revlog. It was made more obvious in 62a532045e71 and related API simplification. It's resolved in favor of passing a revlog because the revlog verification code doesn't have a reference to a filelog. Differential Revision: https://phab.mercurial-scm.org/D7711

revlog: split the content verification of a node into a separate method This will be used by LFS to tune what is skipped. In the future, this could also be used by LFS to indicate which nodes tagged with `skipread` are simply in need of a blob fetch, so that they can be done in a batch later. (Currently, `skipread` also indicates censored data and errors.) Additionally, it could be used to cache the sha1 hash value for each blob so that large blobs don't need to be re-read and re-hashed if they are used by multiple nodes. Differential Revision: https://phab.mercurial-scm.org/D7710

verify: update comment to say that lfs doesn't need fulltext to check renames The reason is that `filelog.renamed()` indirectly calls `filelog.revision()`, which is what accesses the full text. However, LFS wraps `filelog.renamed()` and completely handles the case where an LFS blob is in play by using rawdata. I've got a test to demonstrate that this is the case, and prevent regressions. But the `skipread` flag is set on all lfs revisions when using `--no-lfs`, regardless of whether or not the blobs are local. Just above this, that flag is consulted, causing the rename checks to be skipped. That will need to be loosened up first. Differential Revision: https://phab.mercurial-scm.org/D7709

resourceutil: use `from importlib import resources` Without this patch, we get the following error from when trying to run hg with PyOxidizer: module 'importlib' has no attribute 'resources' I don't know what why that happens, but `from importlib import resources` is the form I would prefer anyway, so let's use that now that the impoort-checker has been fixed. Differential Revision: https://phab.mercurial-scm.org/D7701

import-checker: allow all absolute imports of stdlib modules Before this patch, we didn't allow imports like from importlib import resources (That's the reason I used `import importlib.resources` in D7629.) I think that form is still an absolute import, so I don't think we forbade on purpose. Differential Revision: https://phab.mercurial-scm.org/D7700

help: drop a reference to Windows 9x Differential Revision: https://phab.mercurial-scm.org/D7694

help: clarify that the Windows registry key for hgrc files is systemwide Since there's no version or path info here to distinguish between installations, it is effectively systemwide (unless splitting hairs about the WoW64 registry redirection). Differential Revision: https://phab.mercurial-scm.org/D7693

windows: add a global equivalent to /etc/mercurial for *.rc processing This follows the Unix model of processing this directory immediately after <internal>/*.rc, and prior to the installation relative files. Since the Unix processing supports both a directory and a file (the former overriding the latter), and since %HOME% supports both `*.ini` and `.hgrc` (again, the former overriding the latter), this does too. The Unix file doesn't have a `.` prefix, so it's not used here either. Note that this is the opposite order of processing the exe relative paths. But since it's in agreement with Unix, %HOME% and %USERPROFILE%, it seems reasonable to ignore that. Maybe we can change that and take a BC, because that's something the installer should be controlling, and I can't imagine people having both paths *and* conflicting settings. Differential Revision: https://phab.mercurial-scm.org/D7692