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
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.
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}`
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.
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.
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.
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.
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.
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.
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