Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 23:09:37 -0500] rev 43958
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
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 16:36:09 -0500] rev 43957
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
Matt Harbison <matt_harbison@yahoo.com> [Sun, 22 Dec 2019 00:47:33 -0500] rev 43956
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
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Dec 2019 13:30:48 -0800] rev 43955
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
Martin von Zweigbergk <martinvonz@google.com> [Wed, 18 Dec 2019 13:39:44 -0800] rev 43954
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
Matt Harbison <matt_harbison@yahoo.com> [Tue, 17 Dec 2019 22:36:40 -0500] rev 43953
help: drop a reference to Windows 9x
Differential Revision: https://phab.mercurial-scm.org/D7694
Matt Harbison <matt_harbison@yahoo.com> [Tue, 17 Dec 2019 22:33:37 -0500] rev 43952
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
Matt Harbison <matt_harbison@yahoo.com> [Tue, 17 Dec 2019 22:08:07 -0500] rev 43951
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
Martin von Zweigbergk <martinvonz@google.com> [Fri, 13 Dec 2019 10:31:00 -0800] rev 43950
match: normalize `cwd` early
By having cwd in absolute form, we won't have to adjust it when
passing it to subrepo matchers. This will matter for a coming patch.
Differential Revision: https://phab.mercurial-scm.org/D7650
Martin von Zweigbergk <martinvonz@google.com> [Fri, 13 Dec 2019 11:21:31 -0800] rev 43949
match: make sure `root` argument is always an absolute path (API)
The `root` argument should already be an absolute path, but we had
tests that passed a relative path. This patch fixes up the tests and
adds an assertion.
This assumes that `os.path.isabs('/repo')` will be `True` on all
platforms we care to run tests on. Augie tested for me that it does
work on Windows, so that's good enough for me.
Differential Revision: https://phab.mercurial-scm.org/D7649