Joerg Sonnenberger <joerg@bec.de> [Mon, 06 Jul 2020 15:10:53 +0200] rev 45253
manifest: kill one more instance of the old merge hash hack
Differential Revision: https://phab.mercurial-scm.org/D8766
Joerg Sonnenberger <joerg@bec.de> [Sat, 25 Jul 2020 04:29:17 +0200] rev 45252
dirstate: isolate node len dependency for the pure version
When switching to a 256bit hash function, this still needs adjustment,
but concentrates the change in one place.
Differential Revision: https://phab.mercurial-scm.org/D8815
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jul 2020 08:38:19 -0700] rev 45251
fix: update documentation to reflect preference for --source over --rev
I should have updated the documentation in 5205b46bd887 (fix: add a -s
option to format a revision and its descendants, 2020-03-13) and/or
a6ef1e8e2f6d (fix: mark -r as advanced, 2020-03-13)...
Differential Revision: https://phab.mercurial-scm.org/D8808
Kyle Lippincott <spectral@google.com> [Fri, 24 Jul 2020 16:32:45 -0700] rev 45250
tests: make check-py3-compat.py actually load the specified files correctly
For most uses, this change is essentially a no-op, as this script is generally
only run by test-check-py3-compat.t, which will already put `$TESTDIR/..` in
`$PYTHONPATH`.
When running outside of tests, however, `$PYTHONPATH` is likely not set, causing
check-py3-compat.py to parse the file from the repo, but then import the
installed version, and raise any errors about the installed version, not the one
currently in the repo.
Additionally, this helps users (like me) who have a strange set up where their
home directory (and thus their hg repos) happen to be in a subdirectory of
sys.prefix (which is /usr on my system). Since the '.' entry added to sys.path
takes precedence over the absolute path of `$TESTDIR/..` in `$PYTHONPATH`, the
path to the modules that it imports (and that show up in any stack trace) are
*relative*, meaning that we don't detect them as starting with `sys.prefix`.
Sample non-test invocation, and the difference this change makes (the path for
'error at <path>:<line>' is correct now)::
Before:
```
$ python3 contrib/check-py3-compat.py mercurial/win*.py
mercurial/win32.py: error importing: <ValueError> _type_ 'v' not supported (error at check-py3-compat.py:65)
mercurial/windows.py: error importing: <ModuleNotFoundError> No module named 'msvcrt' (error at check-py3-compat.py:65)
```
After:
```
$ python3 contrib/check-py3-compat.py mercurial/win*.py
mercurial/win32.py: error importing: <ValueError> _type_ 'v' not supported (error at win32.py:11)
mercurial/windows.py: error importing: <ModuleNotFoundError> No module named 'msvcrt' (error at windows.py:12)
```
Differential Revision: https://phab.mercurial-scm.org/D8814
Kyle Lippincott <spectral@google.com> [Fri, 24 Jul 2020 12:13:10 -0700] rev 45249
tests: virtualenv is only used on py2, rename and conditionalize
If I have I have the Debian `python3-virtualenv` package installed on my
machine, the import succeeds but then I receive an AttributeError because the
package is essentially completely different between py2 and py3, and
test-hghave fails.
Differential Revision: https://phab.mercurial-scm.org/D8812
Kyle Lippincott <spectral@google.com> [Thu, 23 Jul 2020 13:31:45 -0700] rev 45248
morestatus: mention --stop even if not using --verbose
Differential Revision: https://phab.mercurial-scm.org/D8811
Martin von Zweigbergk <martinvonz@google.com> [Fri, 24 Jul 2020 11:24:59 -0700] rev 45247
templater: handle None returned from templatedir()
My recent 91aa9bba3dc9 (templater: make templatepaths() return a
single path, or None, 2020-07-21) didn't account for the fact that
`templatedir()` returns `None` in frozen binaries. That is ironic,
since the reason I'm working on this is to add support for built-in
mapfiles in frozen binaries. This patch updates the callers to handle
the `None` case. It's somewhat ugly, but I will have to revisit this
soon anyway, since my goal is to make all callers handle that case by
trying to read the map file using the resources API instead.
Differential Revision: https://phab.mercurial-scm.org/D8810
Martin von Zweigbergk <martinvonz@google.com> [Wed, 22 Jul 2020 00:09:17 -0700] rev 45246
templater: do search for include of unqualified builtin outside of config code
Commit 081b08e4ea13 (templater: look for mapfiles in template paths,
2015-05-15) added support for using things like `%include
map-cmdline.default` to include built-in map files without using a
valid path to them. This patch rewrites that support by moving it into
`_readmapfile()` so it can later be adapted for reading from a
non-file resource.
Differential Revision: https://phab.mercurial-scm.org/D8792
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jul 2020 21:59:12 -0700] rev 45245
templater: switch to lower-level config.parse() in _readmapfile()
I hope to modify this code to also work with resources loaded from
memory (for PyOxidizer support). For that, we'll need to handle the
lookup of relative `%include` path (not joined with the base directory
of the containing file). This patch prepares for that by using
`config.parse()` instead of `config.read()`, since the latter expects
a file in the file system.
As it happens, this change also lets us clean up the `config` class to
not need the `_includepaths` field. That will happen next.
Differential Revision: https://phab.mercurial-scm.org/D8791
Martin von Zweigbergk <martinvonz@google.com> [Tue, 21 Jul 2020 23:50:42 -0700] rev 45244
config: pass both relative and absolute paths to `include` callback
The `include` callback is responsible for loading configs from
`%include` statements. The callback currently gets passed the absolute
path [1] to the config to read. That is created by joining the dirname
of the file that contains the `%include` statement. For PyOxidizer
support, I'm trying to reduce dependence on paths. This patch helps
with that by passing the relative path found in the `%include`
statement (but with username expansion, etc.) to the `include`
callback. It also turns out that the existing callers can easily adapt
to using the relative path. Coming patches will clean that up and then
we'll remove the absolute path from the callback.
[1] The "absolute path" bit is a bit of a lie -- it's going to be an
absolute path if the path that was passed into `config.parse()` was
absolute.
Differential Revision: https://phab.mercurial-scm.org/D8790