Mon, 11 Jul 2022 23:30:24 +0200 perf-bundle: accept --type argument
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Jul 2022 23:30:24 +0200] rev 49413
perf-bundle: accept --type argument
Mon, 11 Jul 2022 23:10:55 +0200 perf-bundle: accept --rev arguments
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Jul 2022 23:10:55 +0200] rev 49412
perf-bundle: accept --rev arguments This is fairly standard nowaday.
Mon, 11 Jul 2022 22:50:59 +0200 perf-bundle: add a new command to benchmark bundle creation time
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Jul 2022 22:50:59 +0200] rev 49411
perf-bundle: add a new command to benchmark bundle creation time
Thu, 28 Jul 2022 14:11:53 +0200 Added signature for changeset f69bffd00abe stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Jul 2022 14:11:53 +0200] rev 49410
Added signature for changeset f69bffd00abe
Thu, 28 Jul 2022 14:11:35 +0200 Added tag 6.2.1 for changeset f69bffd00abe stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Jul 2022 14:11:35 +0200] rev 49409
Added tag 6.2.1 for changeset f69bffd00abe
Tue, 12 Jul 2022 01:34:18 +0200 bundle: introduce a --exact option
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 12 Jul 2022 01:34:18 +0200] rev 49408
bundle: introduce a --exact option I have been wanting this options for a long time.
Mon, 11 Jul 2022 23:59:34 +0200 bundlespec: add documentation about existing option
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 Jul 2022 23:59:34 +0200] rev 49407
bundlespec: add documentation about existing option We have some documentation, lets make it complete.
Wed, 27 Jul 2022 12:07:18 +0200 debug-discovery: apply spelling fixes from Raphaël stable 6.2.1
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 27 Jul 2022 12:07:18 +0200] rev 49406
debug-discovery: apply spelling fixes from Raphaël
Tue, 26 Jul 2022 11:10:43 +0200 tree-discovery: fix the request debug output and progress location stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 11:10:43 +0200] rev 49405
tree-discovery: fix the request debug output and progress location This is now associated with each request.
Tue, 26 Jul 2022 10:48:06 +0200 debug-discovery: deal with case where common is empty stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 10:48:06 +0200] rev 49404
debug-discovery: deal with case where common is empty This code was previously confused by case where: `heads_common == {nullid}`
Tue, 26 Jul 2022 10:39:27 +0200 debug-discovery: do not abort on unrelated repositories stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 10:39:27 +0200] rev 49403
debug-discovery: do not abort on unrelated repositories This is a useful case to consider, so we should not abort in this case. A warning is still issued.
Tue, 26 Jul 2022 10:34:20 +0200 debug-discovery: gather the right number of roundtrips for tree discovery stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 10:34:20 +0200] rev 49402
debug-discovery: gather the right number of roundtrips for tree discovery We where not counting the right amount of request before.
Tue, 26 Jul 2022 10:04:06 +0200 debug-discovery: also gather details on tree-discovery queries type stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 10:04:06 +0200] rev 49401
debug-discovery: also gather details on tree-discovery queries type This is useful to understand the algorithm.
Tue, 26 Jul 2022 04:56:29 +0200 debug-discovery: properly apply remote filtering in "old" mode stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 04:56:29 +0200] rev 49400
debug-discovery: properly apply remote filtering in "old" mode Before this change using `--remote-as-revs` with `--old` had no effect and everything was considered as "common", which is really not what we intended.
Tue, 26 Jul 2022 04:54:59 +0200 debug-discovery: fix a typo in the doc stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 26 Jul 2022 04:54:59 +0200] rev 49399
debug-discovery: fix a typo in the doc The second option should be `--remote-…` as we just talked about `--local-…` already.
Tue, 19 Jul 2022 18:40:20 -0400 packaging: bump dulwich to 0.20.45 stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 19 Jul 2022 18:40:20 -0400] rev 49398
packaging: bump dulwich to 0.20.45 I'm told the new dulwich avoids hg-git test failures.
Tue, 19 Jul 2022 18:33:26 -0400 packaging: update keyring on Windows to avoid spurious stacktraces stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 19 Jul 2022 18:33:26 -0400] rev 49397
packaging: update keyring on Windows to avoid spurious stacktraces When challenged for a network password, this would spew on Windows before it actually used the stored password: ``` Error initializing plugin EntryPoint(name='libsecret', value='keyring.backends.libsecret', group='keyring.backends'). Traceback (most recent call last): File "keyring.backend", line 198, in _load_plugins init_func = ep.load() File "importlib.metadata", line 77, in load module = import_module(match.group('module')) File "importlib", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1030, in _gcd_import File "<frozen importlib._bootstrap>", line 1007, in _find_and_load File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked ModuleNotFoundError: No module named 'keyring.backends.libsecret' Error initializing plugin EntryPoint(name='macOS', value='keyring.backends.macOS', group='keyring.backends'). Traceback (most recent call last): File "keyring.backend", line 198, in _load_plugins init_func = ep.load() File "importlib.metadata", line 77, in load module = import_module(match.group('module')) File "importlib", line 127, in import_module return _bootstrap._gcd_import(name[level:], package, level) File "<frozen importlib._bootstrap>", line 1030, in _gcd_import File "<frozen importlib._bootstrap>", line 1007, in _find_and_load File "<frozen importlib._bootstrap>", line 984, in _find_and_load_unlocked ModuleNotFoundError: No module named 'keyring.backends.macOS' ``` We're kinda threading a needle here because the next version of `keyring` (currently at 23.7.0) requires `importlib-metadata` 3.6+, which PyOxidizer 0.22 doesn't support[1]. [1] https://github.com/indygreg/PyOxidizer/issues/609
Mon, 18 Jul 2022 19:18:00 -0400 setup: use the full executable manifest from `python.exe`
Matt Harbison <matt_harbison@yahoo.com> [Mon, 18 Jul 2022 19:18:00 -0400] rev 49396
setup: use the full executable manifest from `python.exe` The manifest embedded by the build process (before the string here is added) already accounts for the `<requestedExecutionLevel level="asInvoker" ...>` setting. (Note that the PyOxidizer build is missing this, so it will likely trigger the UAC escalation prompt on each run.) However, using `mt.exe` to merge the fragment with what is already in the manifest seems to strip all whitespace, making it unreadable. Since Mercurial can be run via `python.exe`, it makes sense that we would have the same manifest settings (like the supported OS list), though I'm unaware of any functionality this enables. It also has the nice effect of making the content readable from a resource editor. The manifest comes from python 3.9.12. Note that this seems to strip the `<?xml ... ?>` declaration when viewed with ResourceHacker 5.1.7, but this was also the state of things with the previous commit, and `mt.exe "-inputresource:hg.exe;#1" -out:extracted` does contain the declaration and the BOM in both cases. No idea why this differs from other executables.
Mon, 18 Jul 2022 17:19:56 -0400 setup: unconditionally enable the `long-paths-support` option on Windows
Matt Harbison <matt_harbison@yahoo.com> [Mon, 18 Jul 2022 17:19:56 -0400] rev 49395
setup: unconditionally enable the `long-paths-support` option on Windows I don't see anything talking about why this was experimental in the first place, but maybe it was concern about the level of python2 support for it. But now, both `python.exe` and the PyOxidizer build of `hg.exe` have a manifest that enables it, so leaving it off would mean some Mercurial installations could operate on a repo with long paths, and others couldn't. Note that only the wide character functions (XxxW) will have the length restriction lifted. Sadly, distutils applies `/MANIFEST:EMBED` to the linker in a way that can't easily be turned off, so we can't use `/MANIFESTFILE` with `extra_preargs` on `link_executable`. Fortunately, the compiler object provides a path to the `mt.exe` it found during initialization, because the previous incarnation seems to have assumed it is being run within an activated Visual Studio environment. That causes MSYS builds to fail, and probably would have broke the CI environment.
Mon, 18 Jul 2022 17:00:59 -0400 setup: stop shadowing the builtin `dir` symbol
Matt Harbison <matt_harbison@yahoo.com> [Mon, 18 Jul 2022 17:00:59 -0400] rev 49394
setup: stop shadowing the builtin `dir` symbol I hit this when debugging what's available on the compiler.
Mon, 18 Jul 2022 03:29:53 -0400 subrepo: avoid opening console window for non-native subrepos on Windows
derekbrowncmu@gmail.com [Mon, 18 Jul 2022 03:29:53 -0400] rev 49393
subrepo: avoid opening console window for non-native subrepos on Windows Prevent annoying command prompt windows popping up when using TortoiseHG with Git and SVN subrepos by passing creationflags=subprocess.CREATE_NO_WINDOW to subprocess.Popen.
Tue, 19 Jul 2022 12:41:46 +0200 mergestate: action name was str stable
Georges Racinet <georges.racinet@octobus.net> [Tue, 19 Jul 2022 12:41:46 +0200] rev 49392
mergestate: action name was str Apparently the standard for them is still to use byte strings. Found while looking at something else
Wed, 13 Jul 2022 17:13:33 -0400 ci: bump pytype to 2022.03.29
Matt Harbison <matt_harbison@yahoo.com> [Wed, 13 Jul 2022 17:13:33 -0400] rev 49391
ci: bump pytype to 2022.03.29 This is as far as we can go without running into issues with the vendored `attr` package. I tried updating that to the latest, and not only did it not fix the issue, but test-util.py failed due to some poking at `attr` internals that apparently is no longer valid. The `libcst` package is now pinned to what I have locally because trying to install the latest (0.4.7) complains that it can't find the Rust compiler. We should probably use a requirements file instead (and/or figure out why it can't find the Rust compiler), but I don't feel like dealing with another side quest.
Wed, 13 Jul 2022 12:47:40 -0400 typing: suppress a few attribute errors in url.py
Matt Harbison <matt_harbison@yahoo.com> [Wed, 13 Jul 2022 12:47:40 -0400] rev 49390
typing: suppress a few attribute errors in url.py These are newly detected by pytype 2022.03.21. Not sure what is going on here- `realhostport` and `headers` are added outside of the constructor, so that makes sense. But PyCharm also thinks the private methods don't exist, though when clicking through the class hierarchy, it shows in the py3.9 source code.
Wed, 13 Jul 2022 11:30:13 -0400 typing: suppress a few pyi-errors with more recent pytype
Matt Harbison <matt_harbison@yahoo.com> [Wed, 13 Jul 2022 11:30:13 -0400] rev 49389
typing: suppress a few pyi-errors with more recent pytype Not sure what's going on here, but these were flagged with pytype 2022.03.21. We can't update to something much more recent, because newer versions complain about various `attr` uses.
Wed, 13 Jul 2022 18:27:40 +0200 sslutil: another use proper attribute to select python 3.7+ stable
Ondrej Pohorelsky <opohorel@redhat.com> [Wed, 13 Jul 2022 18:27:40 +0200] rev 49388
sslutil: another use proper attribute to select python 3.7+ The previous attribute was python 3.6+, but guarded a python 3.7+ block Using the correct attribute avoids: + File "/tmp/hgtests.bc0_uk2d/install/lib/python/mercurial/sslutil.py", line 577, in wrapserversocket + sslcontext.minimum_version = ssl.TLSVersion.TLSv1_1 + AttributeError: module 'ssl' has no attribute 'TLSVersion'
Tue, 12 Jul 2022 15:59:53 +0200 sslutil: use proper attribute to select python 3.7+ stable
Mathias De Mare <mathias.de_mare@nokia.com> [Tue, 12 Jul 2022 15:59:53 +0200] rev 49387
sslutil: use proper attribute to select python 3.7+ The previous attribute was python 3.6+, but guarded a python 3.7+ block. Using the correct attribute avoids: File "/usr/lib64/python3.6/site-packages/mercurial/sslutil.py", line 334, in wrapsocket sslcontext.minimum_version = ssl.TLSVersion.TLSv1_1 AttributeError: module 'ssl' has no attribute 'TLSVersion'
Wed, 06 Jul 2022 11:52:26 +0400 git: copy findmissingrevs() from revlog.py to gitlog.py (issue6472) stable
Anton Shestakov <av6@dwimlabs.net> [Wed, 06 Jul 2022 11:52:26 +0400] rev 49386
git: copy findmissingrevs() from revlog.py to gitlog.py (issue6472)
Mon, 04 Jul 2022 17:16:13 +0400 git: add a missing reset_copy keyword argument to dirstate.set_tracked() stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 04 Jul 2022 17:16:13 +0400] rev 49385
git: add a missing reset_copy keyword argument to dirstate.set_tracked() Since nothing else in hgext/git supports copies yet, the best I can do is avoid TypeError: set_tracked() got an unexpected keyword argument 'reset_copy'.
Mon, 04 Jul 2022 15:01:52 +0400 git: make sure to fsdecode bookmark names everywhere (issue6723) stable
Anton Shestakov <av6@dwimlabs.net> [Mon, 04 Jul 2022 15:01:52 +0400] rev 49384
git: make sure to fsdecode bookmark names everywhere (issue6723)
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip