Thu, 18 Jun 2020 22:23:22 +0200 phases: improve performance of _retractboundary
Joerg Sonnenberger <joerg@bec.de> [Thu, 18 Jun 2020 22:23:22 +0200] rev 44988
phases: improve performance of _retractboundary The old version repeatedly converts nodes to revisions, which is a moderately expensive operation. Mapping all new changes once to revisions and back at the end reduces the time spend in _retractboundary during the unbundling of NetBSD's src from 67s to 17s. Differential Revision: https://phab.mercurial-scm.org/D8641
Thu, 18 Jun 2020 17:54:39 +0530 tests: use proctutil.stdout.write() instead of print() in test-extension.t
Pulkit Goyal <7895pulkit@gmail.com> [Thu, 18 Jun 2020 17:54:39 +0530] rev 44987
tests: use proctutil.stdout.write() instead of print() in test-extension.t I was debugging this test failure on python3 + chg. I get the following hunk as test failure: ``` @@ -206,6 +206,18 @@ Check normal command's load order of ext 4) bar uipopulate 5) foo reposetup 5) bar reposetup + 4) foo uipopulate (chg !) + 4) bar uipopulate (chg !) + 4) foo uipopulate (chg !) + 4) bar uipopulate (chg !) + 4) foo uipopulate (chg !) + 4) bar uipopulate (chg !) + 4) foo uipopulate (chg !) + 4) bar uipopulate (chg !) + 4) foo uipopulate (chg !) + 4) bar uipopulate (chg !) + 5) foo reposetup (chg !) + 5) bar reposetup (chg !) 0:c24b9ac61126 ``` After hours of debugging and head scracthing, I figured out that something is wrong with output flushing. I initially switched the print() statements to ui.warn() but thanks to Yuya who suggested using procutil.stdout.write() instead.
Wed, 08 Jan 2020 11:33:41 -0500 fuzz: tell manifest fuzzer about longer node hashes
Augie Fackler <augie@google.com> [Wed, 08 Jan 2020 11:33:41 -0500] rev 44986
fuzz: tell manifest fuzzer about longer node hashes Differential Revision: https://phab.mercurial-scm.org/D8374
Mon, 01 Jun 2020 20:57:14 +0200 absorb: preserve changesets which were already empty
Manuel Jacob <me@manueljacob.de> [Mon, 01 Jun 2020 20:57:14 +0200] rev 44985
absorb: preserve changesets which were already empty Most commands in Mercurial (commit, rebase, absorb itself) don’t create empty changesets or drop them if they become empty. If there’s a changeset that’s empty, it must be a deliberate choice of the user. At least it shouldn’t be absorb’s responsibility to prune them. The fact that changesets that became empty during absorb are pruned, is unaffected by this. This case was found while writing patches which make it possible to configure absorb and rebase to not drop empty changesets. Even without having such config set, I think it’s valuable to preserve changesets which were already empty.
Mon, 01 Jun 2020 11:07:33 +0200 absorb: preserve branch-closing changesets even if empty
Manuel Jacob <me@manueljacob.de> [Mon, 01 Jun 2020 11:07:33 +0200] rev 44984
absorb: preserve branch-closing changesets even if empty This makes the behavior consistent with 'hg commit', which allows to create otherwise empty changesets if they close the branch. A lost branch closure can inadvertently re-open a branch, so it should be preserved.
Mon, 01 Jun 2020 10:33:00 +0200 absorb: preserve branch-changing changesets even if empty
Manuel Jacob <me@manueljacob.de> [Mon, 01 Jun 2020 10:33:00 +0200] rev 44983
absorb: preserve branch-changing changesets even if empty This makes the behavior consistent with 'hg commit', which allows to create otherwise empty changesets if the branch changes compared to the parent. A branch change can denote important information, so it should be preserved.
Mon, 22 Jun 2020 15:19:35 +0530 rhg: add Command trait for subcommands implemented by rhg
Antoine Cezar <antoine.cezar@octobus.net> [Mon, 22 Jun 2020 15:19:35 +0530] rev 44982
rhg: add Command trait for subcommands implemented by rhg Normalizes the interface of the cli's commands Differential Revision: https://phab.mercurial-scm.org/D8611 Differential Revision: https://phab.mercurial-scm.org/D8648
Fri, 05 Jun 2020 10:28:58 +0200 rhg: add rhg crate
Antoine Cezar <antoine.cezar@octobus.net> [Fri, 05 Jun 2020 10:28:58 +0200] rev 44981
rhg: add rhg crate The goal of rhg is to speedup some of hg's commands when possible by bypassing python entirely for the time being. It is by no means a replacement for hg as it will not support extentions or configuration and implement only a subset of hg's commands and options. Only use rhg if you understand what the tradeoffs are. Differential Revision: https://phab.mercurial-scm.org/D8610
Fri, 05 Jun 2020 08:48:09 +0200 hg-core: add FindRoot operation to find repository root path
Antoine Cezar <antoine.cezar@octobus.net> [Fri, 05 Jun 2020 08:48:09 +0200] rev 44980
hg-core: add FindRoot operation to find repository root path Differential Revision: https://phab.mercurial-scm.org/D8609
Tue, 23 Jun 2020 16:07:18 +0200 share: provide a more useful text for hg help stable
Joerg Sonnenberger <joerg@bec.de> [Tue, 23 Jun 2020 16:07:18 +0200] rev 44979
share: provide a more useful text for hg help Differential Revision: https://phab.mercurial-scm.org/D8651
Thu, 25 Jun 2020 00:06:23 -0700 procutil: make recent fix for zombies compatible with py2 stable
Martin von Zweigbergk <martinvonz@google.com> [Thu, 25 Jun 2020 00:06:23 -0700] rev 44978
procutil: make recent fix for zombies compatible with py2 The fix in ed684a82e29b (procutil: always waiting on child processes to prevent zombies with 'hg serve', 2020-05-07) works only on Python 3 because it passes a `daemon` argument to `threading.Thread()`. Python 2 requires you to assign to the `.daemon` property instead. Python 3 also seems to support that, so this patch fixes the code by unconditionally using the old form. Differential Revision: https://phab.mercurial-scm.org/D8657
Wed, 24 Jun 2020 04:25:34 +0200 pycompat: fix crash when default locale is unknown stable
Manuel Jacob <me@manueljacob.de> [Wed, 24 Jun 2020 04:25:34 +0200] rev 44977
pycompat: fix crash when default locale is unknown Instead, fall back to the filesystem encoding if the default locale is unknown.
Mon, 22 Jun 2020 22:15:57 -0700 help: document meaning of '%' in graphlog output stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 22 Jun 2020 22:15:57 -0700] rev 44976
help: document meaning of '%' in graphlog output I added the feature in 14d0e89520a2 (graphlog: use '%' for other context in merge conflict, 2020-01-28), but I didn't think to look for documentation until today (because an internal user asked about it). Differential Revision: https://phab.mercurial-scm.org/D8649
Wed, 17 Jun 2020 16:11:11 -0700 py3: fix broken man page generation, it was generating `(default: NUL*)` stable
Kyle Lippincott <spectral@google.com> [Wed, 17 Jun 2020 16:11:11 -0700] rev 44975
py3: fix broken man page generation, it was generating `(default: NUL*)` `bytes(default)` was producing things like `(default: \x00)` when handed non-bytes values such as `1`, `10`, or `True`. The man page generation would apparently ignore these bytes and produce man pages that had the string `(default: )`. Test Plan: - Ran `cd doc; python3 gendoc.py "hg.1.gendoc"` and grepped for bad output - Ran `make deb`, extracted the deb, manually inspected `hg.1` file. Differential Revision: https://phab.mercurial-scm.org/D8639
Fri, 05 Jun 2020 08:46:35 +0200 hg-core: add Operation interface for high-level hg operations
Antoine Cezar <antoine.cezar@octobus.net> [Fri, 05 Jun 2020 08:46:35 +0200] rev 44974
hg-core: add Operation interface for high-level hg operations A distinction is made between operations and commands. An operation is a high-level function of mercurial whereas a command is what is exposed by the cli. A single command can use several operations to achieve its goal. Differential Revision: https://phab.mercurial-scm.org/D8608
Mon, 15 Jun 2020 18:26:40 +0200 rust: do a clippy pass
Raphaël Gomès <rgomes@octobus.net> [Mon, 15 Jun 2020 18:26:40 +0200] rev 44973
rust: do a clippy pass This is the result of running `cargo clippy` on hg-core/hg-cpython and fixing the lints that do not require too much code churn (and would warrant a separate commit/complete refactor) and only come from our code (a lot of warnings in hg-cpython come from `rust-cpython`). Most of those were good lints, two of them was the linter not being smart enough (or compiler to get up to `clippy`'s level depending on how you see it). Maybe in the future we could have `clippy` be part of the CI. Differential Revision: https://phab.mercurial-scm.org/D8635
Tue, 16 Jun 2020 14:38:50 +0200 py3: fix comparison between int and None stable
Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 14:38:50 +0200] rev 44972
py3: fix comparison between int and None If stop is None, the condition was always false on Python 2, as None compares smaller than ints. Therefore we make the condition false if stop is None.
Tue, 16 Jun 2020 14:33:49 +0200 py3: pass regex as bytes stable
Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 14:33:49 +0200] rev 44971
py3: pass regex as bytes
Tue, 16 Jun 2020 14:32:10 +0200 py3: avoid using %r format on bytes stable
Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 14:32:10 +0200] rev 44970
py3: avoid using %r format on bytes Before the patch, the 'b' prefix appeared in the formatted string. Wrapping the bytes as pycompat.bytestr solves this problem. Eventually, I think that we should move away from using %r (like 975e517451a6 and 4d6019c0e0ef did), but that would change output of non-ASCII bytes on Python 2, so we can’t do it on the stable branch. Also, many places continue to use %r, so it would be a good idea to do the change all at once.
Tue, 16 Jun 2020 14:03:00 +0200 py3: use `%d` for int in % formatting stable
Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 14:03:00 +0200] rev 44969
py3: use `%d` for int in % formatting On Python 3, `%s` is an alias to `%b`, which requires that the object implements `__bytes__()`, which is not the case for `int`.
Tue, 16 Jun 2020 14:00:20 +0200 py3: pass native string to urlreq.url2pathname() stable
Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 14:00:20 +0200] rev 44968
py3: pass native string to urlreq.url2pathname() Of course, I’m not happy with the warning, but it’s better than crashing. Solving the problem properly is hard, and non-UTF-8 percent-encoded bytes in file URLs seem rare enough to block solving that all file URLs (even if not SVN-specific) will cause a crash.
Tue, 16 Jun 2020 12:59:45 +0200 py3: suppress DeprecationWarning about deprecated base64 module aliases stable
Manuel Jacob <me@manueljacob.de> [Tue, 16 Jun 2020 12:59:45 +0200] rev 44967
py3: suppress DeprecationWarning about deprecated base64 module aliases base64.encodestring() / base64.decodestring() were renamed to base64.encodebytes() / base64.decodebytes() in Python 3. The old names still worked, but raised a DeprecationWarning.
Mon, 15 Jun 2020 03:38:02 +0200 py3: use `pycompat.ziplist()` stable
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:38:02 +0200] rev 44966
py3: use `pycompat.ziplist()`
Mon, 15 Jun 2020 03:34:23 +0200 py3: use `%d` for int in % formatting stable
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:34:23 +0200] rev 44965
py3: use `%d` for int in % formatting On Python 3, `%s` is an alias to `%b`, which requires that the object implements `__bytes__()`, which is not the case for `int`.
Mon, 15 Jun 2020 03:30:24 +0200 py3: fix bytes iteration stable
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:30:24 +0200] rev 44964
py3: fix bytes iteration
Mon, 15 Jun 2020 03:09:55 +0200 py3: unbyteify arguments to warnings.filterwarnings() stable
Manuel Jacob <me@manueljacob.de> [Mon, 15 Jun 2020 03:09:55 +0200] rev 44963
py3: unbyteify arguments to warnings.filterwarnings() This fixes a crash when trying to import the convert extension on Python 3.
Mon, 15 Jun 2020 15:14:16 -0400 fuzz: add config knob for PYTHON_CONFIG_FLAGS
Augie Fackler <augie@google.com> [Mon, 15 Jun 2020 15:14:16 -0400] rev 44962
fuzz: add config knob for PYTHON_CONFIG_FLAGS I'll clean this up once we get oss-fuzz to use Python 3.8 instead of 2.7, but for now we need a way to evolve the flags passed to python-config in lockstep with the Python version. Yuck. Differential Revision: https://phab.mercurial-scm.org/D8637
Mon, 15 Jun 2020 15:13:01 -0400 pyutil: this has taken so long to fix, I'm using 3.8 now
Augie Fackler <augie@google.com> [Mon, 15 Jun 2020 15:13:01 -0400] rev 44961
pyutil: this has taken so long to fix, I'm using 3.8 now Differential Revision: https://phab.mercurial-scm.org/D8636
Mon, 15 Jun 2020 12:00:15 -0400 merge with stable
Augie Fackler <augie@google.com> [Mon, 15 Jun 2020 12:00:15 -0400] rev 44960
merge with stable
Sat, 06 Jun 2020 19:15:11 +0800 tests: adjust to the new format in pyflakes output stable
Anton Shestakov <av6@dwimlabs.net> [Sat, 06 Jun 2020 19:15:11 +0800] rev 44959
tests: adjust to the new format in pyflakes output According to the pyflakes' NEWS.rst, the default output format changed recently: 2.2.0 (2020-04-08) - Include column information in error messages So the lines now read: contrib/perf.py:149:15 undefined name 'xrange' mercurial/hgweb/server.py:427:13 undefined name 'reload' mercurial/util.py:2862:24 undefined name 'file' This is a graft of a similar fix that ended up on default. Differential Revision: https://phab.mercurial-scm.org/D8630
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip