Wed, 14 Mar 2018 11:52:35 -0700 util: prefer "bytesio" to "stringio"
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 14 Mar 2018 11:52:35 -0700] rev 36958
util: prefer "bytesio" to "stringio" The io.BytesIO and io.StringIO types enforce the type of data being operated on. On Python 2, we use cStringIO.StringIO(), which is lax about mixing types. On Python 3, we actually use io.BytesIO. Ideally, we'd use io.BytesIO on Python 2. But I believe its performance is poor compared to cString.StringIO(). Anyway, we canonically define our pycompat type as "stringio." That name is misleading, especially on Python 3. This commit renames the canonical symbols to "bytesio." "stringio" is preserved as an alias for API compatibility. There are a lot of callers in the repo and I hesitate to take away the old name. I also don't feel like changing everything at this time. But at least new callers can use a "proper" name. Differential Revision: https://phab.mercurial-scm.org/D2868
Wed, 14 Mar 2018 14:05:45 -0400 contrib: fix a subtle bug in check-code's regex rewriting
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 14:05:45 -0400] rev 36957
contrib: fix a subtle bug in check-code's regex rewriting We rewrite `\s` to `[ \t]` when preparing our regular expressions, but we previously weren't working to avoid having nested sets. Previously, Python let this slide without incident, but in Python 3.7 wants to make sure you meant an actual [ in a set, and so this warns. This appears to be fortunate for us, because `[\s(]` was getting rewritten to be `[[ \t](]` which doesn't actually match what we expected. See preceding changes that were revealed to be necessary after implementing this fix. Differential Revision: https://phab.mercurial-scm.org/D2866
Tue, 13 Mar 2018 17:55:03 -0400 remotenames: work around move of ABCs in collections
Augie Fackler <augie@google.com> [Tue, 13 Mar 2018 17:55:03 -0400] rev 36956
remotenames: work around move of ABCs in collections This starts warning in Python 3.7, and will break in 3.8. The import is performed in a curious place because `import collections.abc` explodes badly on Python 2.7, and `from collections import abc` flunks our import checker. Differential Revision: https://phab.mercurial-scm.org/D2847
Mon, 26 Feb 2018 20:44:21 +0800 hgweb: explain instabilities of unstable changesets
Anton Shestakov <av6@dwimlabs.net> [Mon, 26 Feb 2018 20:44:21 +0800] rev 36955
hgweb: explain instabilities of unstable changesets
Mon, 26 Feb 2018 20:44:01 +0800 debug: add debugwhyunstable that explains instabilities
Anton Shestakov <av6@dwimlabs.net> [Mon, 26 Feb 2018 20:44:01 +0800] rev 36954
debug: add debugwhyunstable that explains instabilities This is a port of evolve's feature of listing all unstable changesets in detail (`hg evolve --list`).
Tue, 13 Mar 2018 20:34:38 +0800 obsolete: move marker flags to obsutil
Anton Shestakov <av6@dwimlabs.net> [Tue, 13 Mar 2018 20:34:38 +0800] rev 36953
obsolete: move marker flags to obsutil Evolve extension expects to have obsolete.bumpedfix (imported in hgext3rd/evolve/evolvecmd.py), so we provide it.
Wed, 21 Feb 2018 17:21:10 +0100 debugupdatecache: also warm rev branch cache
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:21:10 +0100] rev 36952
debugupdatecache: also warm rev branch cache We add basic code to have `debugupdatecache` ensure that the rev branch cache is fully warmed. This only affects the `debugupdatecache` command, not normal transaction operation.
Wed, 21 Feb 2018 17:16:56 +0100 debugbundle: do not display detailed part data in --quiet mode
Boris Feld <boris.feld@octobus.net> [Wed, 21 Feb 2018 17:16:56 +0100] rev 36951
debugbundle: do not display detailed part data in --quiet mode This changeset makes `hg debugbundle` respect --quiet and only display data about part headers.
Wed, 14 Mar 2018 15:44:53 -0400 tests: clean up two wayward `python` invocations
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 15:44:53 -0400] rev 36950
tests: clean up two wayward `python` invocations These are also fallout from the check-code regex rewriting bug. Differential Revision: https://phab.mercurial-scm.org/D2865
Wed, 14 Mar 2018 15:42:23 -0400 contrib: open a hole in the open().read() ban for open().close()
Augie Fackler <augie@google.com> [Wed, 14 Mar 2018 15:42:23 -0400] rev 36949
contrib: open a hole in the open().read() ban for open().close() It turns out open().close() is both fine and something we occasionally do to verify something can be written. The few cases in the codebase were getting missed due to a regular expression bug (which I discussed in my previous change), but since I'm about to fix the bug, I need to fix the patterns. Differential Revision: https://phab.mercurial-scm.org/D2864
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip