relnotes: add 6.8.2

evolution: stop wrongly flagging unrelated part of a split as divergent Before this change, divergence introduced by successors of a split would "spill" to other unrelated successors of the split that were not ambiguous. This small changes fixes it. Thanks goes to Manuel Jacobs for the discussion leading to this realization that a new simple and correct definition could be found.

tests: skip doctests that use `time.tzset()` on Windows There's no way to conditionally skip the tests for a function (see the inline feature request). That leaves us with the choice to either put the whole `mercurial.utils.dateutil` module in the skip list of this script (but then this script prints out the module as unexpectedly not tested, and misses a bunch of tests that can be run), blacklist the test entirely (but that makes it harder to work with on Windows), or use this hack to look for the statement that is broken, and skip the test currently attached to one function. (It appears that an example in the list of examples corresponds to a single `>>>` block, and the `test` itself corresponds to a single function. So prescan the examples, and skip all of them when the statement is found in any, since the setup of setting the timezone has an effect on subsequent examples.)

tests: hopefully fix `test-doctest.py` on Windows and more 1. Shell syntax understood by `shell=True` depends on the platform. Instead, pass `shell=False` and call `sh` explicitly to interpret the command correctly. 2. Stop setting `HGRCPATH=/dev/null`, so the setting `experimental.evolution=createmarkers` is set correctly. The reason I set HGRCPATH to /dev/null previously is because of misunderstanding where I thought the Python script had no HGRC to edit. As it turns out, there is in fact a valid temporary HGRC pointed to by HGRCPATH in this context so we don't seem to need this. /shrug

hghave: make the description for "clang-format" ascii test-fix-clang-format.t suddenly started failing on Windows by wiping the whole file content, and replacing with an error: $TESTTMP.sh: $TESTTMP.sh: cannot execute binary file Odd, because I don't have `clang-format` installed, so the test should be skipped. The problem started with 73cf8b56c2f5, and I noticed that running `hghave` manually resulted in a `SyntaxError` (so I can't see how this isn't broken everywhere, but maybe it's because I'm using py3.9 on Windows): $ py hghave --list Traceback (most recent call last): File "hghave", line 8, in <module> import hghave File "c:\Users\Matt\hg\tests\hghave.py", line 627 SyntaxError: Non-ASCII character '\xe2' in file c:\Users\Matt\hg\tests\hghave.py on line 627, but no encoding declared; see http://python.org/dev/peps/pep-0263/ for details

branching: merge stable into default Hopefully this will bring the last changes necessary to make the 3.13 tests green (on Linux).

tests: enable pytype checking on `mercurial/wireprotov1peer.py`

typing: suppress bogus pytype errors in `mercurial/wireprotov1peer.py` Fixes: File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 100, in result: No attribute '_peerexecutor' on unsentfuture [attribute-error] File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 278, in close: No attribute 'shutdown' on None [attribute-error] Called from (traceback): line 123, in __exit__ File "/mnt/c/Users/Matt/hg/mercurial/wireprotov1peer.py", line 278, in close: No attribute 'shutdown' on None [attribute-error] In Optional[concurrent.futures.thread.ThreadPoolExecutor] We drop the zope decorator on `peerexecutor`, because otherwise it triggers this error: File "/tmp/mercurial-ci/mercurial/wireprotov1peer.py", line 111, in <module>: Invalid type annotation [invalid-annotation] Must be constant Not sure why, because the decorated classes usually get typed as `Any`, which would also be fine here.

tests: enable pytype checking on `mercurial/wireprotoframing.py`

typing: suppress bogus pytype errors in `mercurial/wireprotoframing.py` This fixes: File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 480, in createalternatelocationresponseframe: unsupported operand type(s) for item assignment: bytes [unsupported-operands] No attribute '__setitem__' on bytes File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 510, in createcommanderrorresponse: unsupported operand type(s) for item assignment: bytes [unsupported-operands] No attribute '__setitem__' on bytes File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 776, in __init__: Can't find module 'mercurial.zstd'. [import-error] File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 804, in __init__: Can't find module 'mercurial.zstd'. [import-error] File "/mnt/c/Users/Matt/hg/mercurial/wireprotoframing.py", line 834, in populatestreamencoders: Can't find module 'mercurial.zstd'. [import-error] Using `TypedDict` is tempting here to fix the first two, but requires str keys. The code doing the importing doesn't call the code at the other three locations if the `mercurial.zstd` module fails to import in a place that handles the ImportError.

wireprototypes: make `baseprotocolhandler` methods abstract The documentation says it's an abstract base class, so let's enforce it. The `typing.Protocol` class is already an ABC, but it only prevents instantiation if there are abstract attrs that are missing. For example, from `hg debugshell`: >>> from mercurial import wireprototypes >>> x = wireprototypes.baseprotocolhandler() Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: Can't instantiate abstract class baseprotocolhandler with abstract method name >>> class fake(wireprototypes.baseprotocolhandler): ... pass ... >>> x = fake() Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: Can't instantiate abstract class fake with abstract method name That's great, but it doesn't protect against calling non-abstract methods at runtime, rather it depends on the protocol type hint being added to method signatures or class attrs, and then running a type checker to notice when an instance is assigned that doesn't conform to the protocol. We don't widely use type hints yet, and do have a lot of class hierarchy in the repository area, which could lead to surprises like this: >>> class fake(wireprototypes.baseprotocolhandler): ... @property ... def name(self) -> bytes: ... return b'name' ... >>> z = fake() >>> z.client() >>> print(z.client()) None Oops. That was supposed to return `bytes`. So not only is a bad/unexpected value returned, but it's one that violates the type hints (since the base client() method will be annotated to return bytes). With this change, we get: >>> from mercurial import wireprototypes >>> class fake(wireprototypes.baseprotocolhandler): ... @property ... def name(self) -> bytes: ... return b'name' ... >>> x = fake() Traceback (most recent call last): File "<console>", line 1, in <module> TypeError: Can't instantiate abstract class fake with abstract methods addcapabilities, checkperm, client, getargs, getpayload, getprotocaps, mayberedirectstdio So this looks like a reasonable safety harness to me, and lets us catch problems by running the standard tests while the type hints are being added, and pytype is improved. We should probably do this for all Protocol class methods that don't supply a method implementation.

wireprototypes: convert `baseprotocolhandler.name` to an abstract property PyCharm was flagging the subclasses where this was declared as a `@property` with Type of 'name' is incompatible with 'baseprotocolhandler' But pytype didn't complain. This seems more correct, however. Since `Protocol` is already an `abc.ABCMeta` class, we don't need to mess with the class hierarchy.

wireprotoserver: subclass the new `baseprotocolhandler` Protocol class

wireprototypes: convert `baseprotocolhandler` to a Protocol class The methodology for doing this is now known, and this is limited to two implementing classes, so just make the changes.

test: stabilize `test-audit-path.t` in rust (hopefully) We have been seeing flakiness on the file reported for a bit.

pycompat: drop test involving assigning "foo" to `sys.hexversion` Starting with python 3.13, `sys.hexversion` refuse to be assigned non-hex value like "foo". I don't think I can blame it. It is time to drop that part of the tests.

pycompat: filter more of the traceback in `test-flagproccessor.t` The traceback changes again with 3.13. So we filter it to only keeps the bits we care about. This is actually only reusing the approach from a few line below.

pycompat: ignore the fork + thread warning for now No known issues has been reported and this is breaking the CI quite hard. So for now we have to delay the issue.

wireprototypes: fix exception handling code with a bad pytype suppression This goes back to f5fcf7123a92, and I suspect it was a misread of the error message is describes- the LHS of `.sorted()` is always bytes, and bytes didn't have this method in py2 either. The invalid names were already handled like this a few lines above. PyCharm flagged this, and it stood out after converting the zope interfaces to Protocol classes (which hasn't been published yet).

tests: conditionalize undesired output on Windows for rbc the mmap cases I don't want to lose sight of this issue, and it's useful to be able to turn on mmap support to hack on the underlying problem. As noted in the previous commit, I think the current usage of `mmap` and `memoryview` needs to be reworked for correctness on posix anyway.

rev-branch-cache: disable mmapping by default on Windows See the inline comment for why. The commands work, other than leaving extra files laying around. Perhaps there's some way to get this to work like on posix with some `CreateFile` magic (though it already uses `FILE_SHARE_DELETE`, so I'm not sure offhand what else we can do). However big picture- it seems wrong that the old file is left mmapped, a new one moved into place, and the mapping left over the old file instead of retargeted to the new file. That's got to be a bug on posix too, in a long running process like chg, right? If the memory is read again for some reason, it will be stale data.

tests: actually test the non-mmap case in `test-branches.t` It looks like 40943970b7ae renamed the config, but also flipped it to 'on' by default, and the test file didn't keep up. I noticed because all 4 test cases failed on Windows due to a mmap problem, and there only should have been 2.

tests: dump the http server log after a clone in `test-static-http.t` The 404 message lines don't match `$LOGDATE$`, because that tests for a pattern from the first "-" through a "(GET|PUT|POST)", so glob the timestamp away manually.

tests: force `dumbhttp.py` to write its log file with '\n' on Windows This wasn't causing obvious test failures, but it's the same fix as dbd2d56224d1 for `dummysmtpd.py`, and there's no sense in leaving this problem lying around. (And upon further review, it might have been causing some non-obviously related failures- see the next commit.)

branching: merge stable into default

rust: address 'error: unnecessarily eager cloning of iterator items' Build failed with a reference to https://rust-lang.github.io/rust-clippy/master/index.html#iter_overeager_cloned which seems reasonable. There doesn't seem to be any reason to not follow the advice.

utils: fix resourceutil use of deprecated importlib.resources Some importlib functionality was deprecated in 3.11 . The documentation on https://docs.python.org/3.12/library/importlib.resources.html recommends using the new .files() API that was introduced in 3.9.

utils: avoid using internal _imp.is_frozen() imp has been deprecated for a long time, and were removed in Python 3.12 . As a workaround, we started using the internal _imp. That is ugly and risky. It seems less risky to get the functionality in some other way. Here, we just inspect if 'origin' of the '__main__' module is set and 'frozen'. That seems to work and do the same, and might be better than using the internal _imp directly. This way of inspecting module attributes seems to work in some test cases, but it is a risky change. This level of importlib doesn't have much documentation, a complicated implementation, and we are dealing with some odd use cases.

cext: use sys.executable instead of deprecated Py_GetProgramFullPath Fix warning with Python 3.13: mercurial/cext/parsers.c: In function 'check_python_version': mercurial/cext/parsers.c:1243:30: warning: 'Py_GetProgramFullPath' is deprecated [-Wdeprecated-declarations] 1243 | Py_GetProgramFullPath()); | ^~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/python3.13/Python.h:119, from mercurial/cext/parsers.c:11: /usr/include/python3.13/pylifecycle.h:43:43: note: declared here 43 | Py_DEPRECATED(3.13) PyAPI_FUNC(wchar_t *) Py_GetProgramFullPath(void); | ^~~~~~~~~~~~~~~~~~~~~ At this point in time, the PyConfig struct memory has been released and the PyConfig API can't be used. https://docs.python.org/3.13/c-api/init.html#c.Py_GetProgramFullPath recommands using sys.executable instead. Let's assume that will work in all versions. It would perhaps be better to use PySys_GetObject, but I prefer to stay consistent with how the same function is retrieving sys.hexversion.

subrepoutil: pass re.sub 'count' argument by name Python 3.13 started warning: DeprecationWarning: 'count' is passed as positional argument

tests: pass re.MULTILINE to re.sub as 'flags' - not in 'count' position This bug was caught by the new Python 3.13 warning: DeprecationWarning: 'count' is passed as positional argument

tests: use packaging from setuptools instead of deprecated distutils When invoking StrictVersion in 3.12 we got: DeprecationWarning: distutils Version classes are deprecated. Use packaging.version instead. distutils is dead in the standard library, and we have to move towards using `setuptools` as general extern dependency. Instead of also requiring the extern `packaging`, we will just use the packaging that is vendored in setuptools.

tests: drop test-demandimport.py distutils test that failed with warnings The test would fail because warnings: /usr/lib/python3.11/site-packages/_distutils_hack/__init__.py:18: UserWarning: Distutils was imported before Setuptools, but importing Setuptools also replaces the `distutils` module in `sys.modules`. This may lead to undesirable behaviors or errors. To avoid these issues, avoid using distutils directly, ensure that setuptools is installed in the traditional way (e.g. not an editable install), and/or make sure that setuptools is always imported before distutils. warnings.warn( /usr/lib/python3.11/site-packages/_distutils_hack/__init__.py:33: UserWarning: Setuptools is replacing distutils. warnings.warn("Setuptools is replacing distutils.") The test for distutils.msvc9compiler comes from 2205d00b6d2b. But since then, distutils is going away, and this test must change somehow. It is unclear exactly how setuptools depended on msvc9compiler, but setuptools also moved forward, and this exact test no longer seems relevant. It thus seems like a fair solution to remove the test while keeping the demandimport blacklist of distutils.msvc9compiler.

utils: test coverage of makedate Explore the scenario from ae04af1ce78d to avoid future regressions. This was intended to give some coverage of the change in faccec1edc2c.

filecache: use bytes wherever possible in the tests This is closer than the actual usage, so I figured in would not hurt.

cachestat: avoid creating cachestat for http path The statichttprepo repo attemp to create cachestat for content we access through http. We modify the couple of place create cachestat object to detect this situation and avoids it. This is not marvelous, but there is few of them and the freeze is looming. This helps on Windows where calling cachestat on http path might create issues.

filecache: use binary path in the test This was overlooked when converting string. This is needed as we are about to introduce bytes specific code in the filecache code path.

branching: merge stable into default

py-3-13: stabilize the docstring output across all supported Python versions Python 3.13 now trims indents from docstrings at compilation time (to save space in .pyc), so all of our helptext is affected. The indentation has never served a user-facing purpose and was more here because nobody cared enough to remove it: we gain some screen space this way. Rather than undo the transformation (which isn't really possible since the transform also deletes leading/trailing whitespace), we align the behavior of older Python versions with that of 3.13. Unfortunately, this means breaking some of the translations. I've only touched the ones that need to work for some tooling tests to pass, but I do not have the time to fix the rest of them across all languages, since they cannot be done in an automated way. i18n updates have been basically abandonned for a good while now, hopefully someone cares enough to bring them back.

docstring: backed out changeset 51057ab0dffa In retrospect this is too much of a behavior change for stable. So I grafted the same change as 31076a2301f1 on default, and I am backing out its version on stable.

tests: stabilize `test-clonebundles-autogen.t` on Windows The problem was that the commands are spun up with `shell=True`, which uses `cmd.exe`, which doesn't understand `$foo` style variables. The HGCB variable expansion has to be delayed, because it's figured out right before launching the command. We could probably add a conditional for Windows, and rewrite the config to use `%foo%` style variables, but it's more maintainable to just wrap the command in a bash shell invocation. The forward style slashes in the path are needed to avoid accruing double backslashes (when switching between shells- the url template seems fine). Also need to strong quote the command so that the double quotes don't get stripped off of `$HGCB_BUNDLE_PATH`, which results in: sh: 1: Syntax error: Unterminated quoted string abort: command returned status 2: sh -c "cp $HGCB_BUNDLE_PATH $TESTTMP/final-upload/"

clonebundles: stop shell quoting `HGCB_BUNDLE_BASENAME` environment variable This causes problems in `test-clonebundles-autogen.t` on Windows, because the quoted path ends up being passed to the `cp` command, which fails, because quote characters are not a legal part of a file name. I don't see any quoting in environment variables on either MSYS or WSL, even with weird ones that appear to have escape sequences like `PS1=\[\033]0;$MSYSTEM:\w\007` (in MSYS). The quoting was added back in 5ae30ff79c76, and as shown here, was causing problems even on posix when a quote was slipped into the path. (The other obvious problem is that the command is spun up shell style, which invokes `cmd.exe`, which doesn't know about `$foo` style variables. That will be addressed next, but that change didn't work without this too.)

tests: add coverage to for `HGCB_BUNDLE_BASENAME` with special characters Per request on IRC, to show the behavior of dropping the quoting of `HGCB_BUNDLE_BASENAME` in the next commit. This current failure is basically the same error and output that currently happens on Windows with any path (even without the embedded quote). The only difference is Windows doesn't print the `cp: cannot stat ...` line.

tests: stabilize `test-eol-update.t` on Windows Perhaps it's better if this doesn't happen, but there are a bunch of tests that spew this, and we already have a conditional match for this in the block prior to the comment right above this section. So accept it as a possibility, and reduce the noise in the Windows tests.

tests: force `dummysmtpd.py` to write its log file with '\n' on Windows The log files were being `cat'd` in `test-patchbomb-tls.t`, and causing gratuitous failures. Since `sys.stdout` is being written to with `str` instead of `bytes`, use a `io.TextIOWrapper` to change the EOL, like 2924676d4728.

tests: raise the default value for the various `devel.sync.*-timeout` configs These are used in `mercurial.testing.wait_file()` to stall for a file to appear in the filesystem, and raise an error if the file doesn't show up before the timeout expires. The default of 2s was way too low on Windows, especially when running tests in parallel, and resulted in various timeouts in `test-dirstate-read-race.t`, `test-dirstate-status-write-race.t`, and `test-clone-stream-revlog-split.t`. The various `wait-on-file` invocations in the tests are inconsistent, and wait anywhere from 5s - 20s. I'm using 20s here because if everything is working, the timeout won't matter. Also with the default timeout being raised on Windows in f4c038081561, both `HGTEST_TIMEOUT_DEFAULT` and `HGTEST_TIMEOUT` are 1440 in the default case where the timeout is not specified on the command line of the test runner, so the timing factor that is multipled with the value is 1, resulting in no changes. (But if someone specified a lower value on the command line, that would *lower* the timeout period used.)

tests: remove deprecated test-check-py3-compat.t If our current source files were not compatible with Python 3, we would know by now. This check has not been relevant for a couple of years now and we can safely remove it.

zope-interface: add compatibility with 3.13 compiler attributes We could follow-up with an actual vendoring update from the newest version of zope-interface in the new cycle since we're dropping 3.7 and down. However we are also in the process of replacing zope-interface with Protocol, so hopefully we can simply drop the zope-interface vendoring.