Tue, 14 Apr 2020 06:09:14 +0200 upgrade: support upgrade and downgrade from persistent nodemap
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Apr 2020 06:09:14 +0200] rev 44841
upgrade: support upgrade and downgrade from persistent nodemap The requirements is now recognised and dealt with and the associated files properly handled. The persistent nodemap should be ready for usage in the field now. Differential Revision: https://phab.mercurial-scm.org/D8431
Tue, 12 May 2020 11:39:50 +0200 status: also support for `traversedir` callback in the Rust fast-path
Raphaël Gomès <rgomes@octobus.net> [Tue, 12 May 2020 11:39:50 +0200] rev 44840
status: also support for `traversedir` callback in the Rust fast-path Repeating the performance numbers from the `hg-core` change: Running `hg clean/purge` on Netbeans' repo (100k files): ``` | No-op | 30% unknown -------------------------- Rust | 1.0s | 1.67s C | 2.0s | 2.87s ``` Differential Revision: https://phab.mercurial-scm.org/D8520
Tue, 12 May 2020 11:37:55 +0200 rust-hg-cpython: update status bridge with the new `traversedir` support
Raphaël Gomès <rgomes@octobus.net> [Tue, 12 May 2020 11:37:55 +0200] rev 44839
rust-hg-cpython: update status bridge with the new `traversedir` support Differential Revision: https://phab.mercurial-scm.org/D8519
Tue, 12 May 2020 11:36:52 +0200 rust-status: collect traversed directories if required
Raphaël Gomès <rgomes@octobus.net> [Tue, 12 May 2020 11:36:52 +0200] rev 44838
rust-status: collect traversed directories if required Some commands (`hg purge` notably) register the `traversedir` callback on their matcher to run said callback every time a directory is traversed. This is the first of three patches, further broadening Rust support for status. Unfortunately, there is no way around collecting a full `Vec` (or any other owned datastructure, like a radix tree) and pushing it back up the Python layer since keeping the Python callback in a closure would mean giving up multithreading because of the GIL, which is obviously unacceptable. Performance is still a lot better than the Python+C path. Running `hg clean/purge` on Netbeans' repo (100k files): ``` | No-op | 30% unknown -------------------------- Rust | 1.0s | 1.67s C | 2.0s | 2.87s ``` Differential Revision: https://phab.mercurial-scm.org/D8518
Tue, 12 May 2020 12:41:28 +0200 rust-status: don't dispatch unknown file when traversing if not listing unknowns
Raphaël Gomès <rgomes@octobus.net> [Tue, 12 May 2020 12:41:28 +0200] rev 44837
rust-status: don't dispatch unknown file when traversing if not listing unknowns This usually isn't a (functional) problem since we ignore the unknown files anyway, but when specifically using `hg purge`, unknown files were iterated over regardless of the option being true. This is both more correct and more efficient. Differential Revision: https://phab.mercurial-scm.org/D8517
Tue, 12 May 2020 10:03:51 +0200 status: update comment to reflect the more recent situation
Raphaël Gomès <rgomes@octobus.net> [Tue, 12 May 2020 10:03:51 +0200] rev 44836
status: update comment to reflect the more recent situation This is a gratuitous cleanup. Differential Revision: https://phab.mercurial-scm.org/D8516
Fri, 01 May 2020 01:32:08 +0200 hooks: provide access to transaction changes for internal hooks
Joerg Sonnenberger <joerg@bec.de> [Fri, 01 May 2020 01:32:08 +0200] rev 44835
hooks: provide access to transaction changes for internal hooks External hooks are skipped here as the environment often has a size limit in the low MBs and that can easily be reached by larger transactions. Differential Revision: https://phab.mercurial-scm.org/D8490
Thu, 07 May 2020 23:54:37 +0200 rust-regex: add test for verbatim regex syntax
Raphaël Gomès <rgomes@octobus.net> [Thu, 07 May 2020 23:54:37 +0200] rev 44834
rust-regex: add test for verbatim regex syntax This makes sure it's not modified. Differential Revision: https://phab.mercurial-scm.org/D8508
Thu, 07 May 2020 23:53:12 +0200 rust-regex: prevent nonsensical `.*.*` pattern from happening
Raphaël Gomès <rgomes@octobus.net> [Thu, 07 May 2020 23:53:12 +0200] rev 44833
rust-regex: prevent nonsensical `.*.*` pattern from happening Differential Revision: https://phab.mercurial-scm.org/D8507
Thu, 07 May 2020 23:52:08 +0200 rust-regex: fix issues with regex anchoring and performance
Raphaël Gomès <rgomes@octobus.net> [Thu, 07 May 2020 23:52:08 +0200] rev 44832
rust-regex: fix issues with regex anchoring and performance It turns out that the way I tried to work around `regex`'s behavior difference with `re2` and Python's `re` was 1) buggy and 2) much more complicated than needed. In a few words: `regex` adds `.*` on either side of patterns when no start or end anchor is present. My previous workaround put `^` or `$` for every pattern, which is wrong even without the other 2 bugs on top of it. Using `^(?:<patterns>)` right at the end of the `regex` path fixes the issue. I've opened an issue to get a build option instead: https://github.com/rust-lang/regex/issues/675 Differential Revision: https://phab.mercurial-scm.org/D8506
Thu, 07 May 2020 16:56:03 -0400 diff: avoid going from contexts to nodes and back
Augie Fackler <augie@google.com> [Thu, 07 May 2020 16:56:03 -0400] rev 44831
diff: avoid going from contexts to nodes and back This will allow us to pass in-memory contexts that may not have a valid node to the diffing logic. Differential Revision: https://phab.mercurial-scm.org/D8503
Fri, 15 May 2020 00:53:37 +0200 setup: raise minimum Python version to 2.7.4 stable
Manuel Jacob <me@manueljacob.de> [Fri, 15 May 2020 00:53:37 +0200] rev 44830
setup: raise minimum Python version to 2.7.4 On older Python versions, Mercurial is not really usable because of https://bugs.python.org/issue10211. Recently someone reported a crash on the mailing list when running Mercurial on Python 2.7.3. There was consensus that fixing compatibility for a Python version more than 7 years old is not worth it. So, instead of making Mercurial crash with an obscure exception, this patch raises the minimum Python version to 2.7.4.
Tue, 19 May 2020 16:18:41 -0400 fsmonitor: coerce `clock` variable to byte-string (issue6321) stable
Connor Sheehan <sheehan@mozilla.com> [Tue, 19 May 2020 16:18:41 -0400] rev 44829
fsmonitor: coerce `clock` variable to byte-string (issue6321) Callers of `fsmonitor.state.setlastclock` pass their arguments wrapped in `pycompat.sysbytes` to ensure the value is a `bytes` on Python 3. However in `fsmonitor.poststatus.__call__`, if the return value of `getlastclock()` is `None`, we use the value of `fsmonitor.poststatus._startclock` instead, which is not converted to a byte string in the same manner. This commit converts the value of `startclock` to a byte string using `pycompat.sysbytes` in the constructor for `poststatus`, to avoid the "`str` + `bytes`" error from issue 6321. Differential Revision: https://phab.mercurial-scm.org/D8573
Thu, 14 May 2020 23:14:24 -0400 py3: change default priority and length used for sorting hooks to be compatible with python 3 stable
Charles Chamberlain <cchamberlain@janestreet.com> [Thu, 14 May 2020 23:14:24 -0400] rev 44828
py3: change default priority and length used for sorting hooks to be compatible with python 3 The call to `sorted(hooks.values())` can on line 213 of hooks.py can raise when using python 3. For instance, when hooks.values is `[(0, 2, b'post-commit.check-status', b''), (None, None, b'changegroup.app-hooks', <object object at 0x7f5279885590>)]`, the error is `TypeError: '<' not supported between instances of 'NoneType' and 'int'` This fix keeps the same order that was used in python 2 without relying on comparison with None. Differential Revision: https://phab.mercurial-scm.org/D8527
Mon, 18 May 2020 08:31:32 -0700 relnotes: copy "next" to "5.4" and clear "next" stable
Martin von Zweigbergk <martinvonz@google.com> [Mon, 18 May 2020 08:31:32 -0700] rev 44827
relnotes: copy "next" to "5.4" and clear "next" This is the same thing as we've done for the previous few releases. Differential Revision: https://phab.mercurial-scm.org/D8546
Mon, 11 May 2020 13:08:02 +0200 dirstate: make sure the dirstate is loaded before the changelog (issue6303) stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 11 May 2020 13:08:02 +0200] rev 44826
dirstate: make sure the dirstate is loaded before the changelog (issue6303) Before this change, it was possible for the changelog to be loaded before the dirstate. If a transaction happens betwen the changelog and dirstate reading, the dirstate can up end poitning toward a revision not existing in the (olded) changelog. This lead to a warning. With this revision, we preload the dirstate parent before reading the changelog. This has a negligible performance impact on performance for all case we are tracking. Differential Revision: https://phab.mercurial-scm.org/D8528
Mon, 11 May 2020 16:44:11 +0200 rust-dirstatemap: don't read the dirstate when requesting parents stable
Raphaël Gomès <rgomes@octobus.net> [Mon, 11 May 2020 16:44:11 +0200] rev 44825
rust-dirstatemap: don't read the dirstate when requesting parents A future patch for issue 6303 reveals a big performance regression in the Rust `DirstateMap` that reads the entire dirstate when requesting parents instead of the first 40 bytes. `perfdiscovery` gets a *significant* speedup (from 0.101 to 0.016) when applied against said patch. I'm assuming it has other performance benefits, but this is already a good enough win. Differential Revision: https://phab.mercurial-scm.org/D8513
Thu, 14 May 2020 10:24:52 -0400 py3: fix exception in pull when several things happen to a bookmark stable
Valentin Gatien-Baron <vgatien-baron@janestreet.com> [Thu, 14 May 2020 10:24:52 -0400] rev 44824
py3: fix exception in pull when several things happen to a bookmark Specifically, when `changes` is: [(b'@upstream-committed', None, <function ui.status>, b'updating bookmark @upstream-committed\n'), (b'@upstream-committed', binary-node, <function ui.warn>, b'divergent bookmark @ stored as @upstream-committed\n')] sorting the list raises: TypeError: '<' not supported between instances of 'bytes' and 'NoneType' Differential Revision: https://phab.mercurial-scm.org/D8523
Thu, 07 May 2020 16:54:17 -0400 cleanup: avoid extra node/ctx conversions in logcmdutil.diffordiffstat
Augie Fackler <augie@google.com> [Thu, 07 May 2020 16:54:17 -0400] rev 44823
cleanup: avoid extra node/ctx conversions in logcmdutil.diffordiffstat I'm about to write some code that wants to pass a memctx to diffordiffstat, but this feels like a meritorious cleanup anyway, since the first thing this method does is turn nodes into contexts, and most callers have a context handy. Differential Revision: https://phab.mercurial-scm.org/D8502
Tue, 12 May 2020 13:06:34 -0700 pyoxidizer: formatting bazel definitions
Rodrigo Damazio Bovendorp <rdamazio@google.com> [Tue, 12 May 2020 13:06:34 -0700] rev 44822
pyoxidizer: formatting bazel definitions This meets the Bazel style guide: https://docs.bazel.build/versions/master/skylark/bzl-style.html and was mostly done automatically with buildifier. Differential Revision: https://phab.mercurial-scm.org/D8521
Tue, 12 May 2020 22:20:56 +0200 fastexport: adjust output to be more canonical stable
Joerg Sonnenberger <joerg@bec.de> [Tue, 12 May 2020 22:20:56 +0200] rev 44821
fastexport: adjust output to be more canonical For time zones, git doesn't consider +0 and -0 the same timezone, so use the former canonically. Add a test case to ensure that non-UTC offsets are handled correctly. The real name part of the committer name is normally not quoted, so don't enforce that. Differential Revision: https://phab.mercurial-scm.org/D8522
Mon, 11 May 2020 08:13:40 +0200 bash_completion: do not use aliased hg if it sources a script (issue6308) stable
Peter Arrenbrecht <peter@arrenbrecht.ch> [Mon, 11 May 2020 08:13:40 +0200] rev 44820
bash_completion: do not use aliased hg if it sources a script (issue6308) I have an alias that sources a script around hg. Mercurial's bash_completion script tries to use this as its main hg binary. But sourcing a wrapper breaks Bash's completion. So this patch disables using the alias as the hg binary if it starts with "source ". Alias resolution was introduced in rev 191ab08e7099 for users with "alias hg='hg --some_opts'". See https://www.mercurial-scm.org/repo/hg/rev/191ab08e7099
Tue, 12 May 2020 01:03:12 +0200 demandimport: fix compatibility with meta path finders w/o find_spec() method stable
Manuel Jacob <me@manueljacob.de> [Tue, 12 May 2020 01:03:12 +0200] rev 44819
demandimport: fix compatibility with meta path finders w/o find_spec() method Meta path finders got a find_spec() method in Python version 3.4. The sys.meta_path documentation says that the deprecated find_module() method is used as a fallback. Setuptool’s VendorImporter still doesn’t have the find_spec() method, which resulted in a crash e.g. within a virtual environment. For reference, I opened an issue for that: https://github.com/pypa/setuptools/issues/2104. An alternative implementation would have been to implement a wrapper for find_module() itself and raise an AttributeError when accessing find_spec() if the wrapped finder doesn’t have it.
Thu, 07 May 2020 23:40:05 +0200 tests: fix timer scaling in wait-on-file stable
Joerg Sonnenberger <joerg@bec.de> [Thu, 07 May 2020 23:40:05 +0200] rev 44818
tests: fix timer scaling in wait-on-file When using the default test timeouts, wait-on-file would not wait for $n seconds, but $n/100 seconds. This resulted in easy timeouts on even moderately busy fast machines. Fix the scaling to apply in all cases. Adjust the stepping slightly to be nicer to systems with the historic 100Hz time base to ensure that the scheduler actually switches to a different process and gives them time to work. Differential Revision: https://phab.mercurial-scm.org/D8505
Sat, 09 May 2020 20:25:07 +0200 manifest-cache: ignore IOError while writing stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 09 May 2020 20:25:07 +0200] rev 44817
manifest-cache: ignore IOError while writing If the wcache directory is non writable for some reason (eg: belong to root). Trying to write to it currently crash Mercurial. Instead we ignore the error and skip writing that cache. We should probably improve the user experience of multiple users interacting with the same repository. However this is not an adventure for stable. Differential Revision: https://phab.mercurial-scm.org/D8512
Wed, 06 May 2020 11:40:17 -0700 copy: give better error message when no source paths found with --at-rev stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:40:17 -0700] rev 44816
copy: give better error message when no source paths found with --at-rev The new error message matches what we show when marking copies in the working copy. Differential Revision: https://phab.mercurial-scm.org/D8496
Wed, 06 May 2020 11:41:37 -0700 tests: show poor error message for `hg cp -A --at-rev . non-existent dst` stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:37 -0700] rev 44815
tests: show poor error message for `hg cp -A --at-rev . non-existent dst` Differential Revision: https://phab.mercurial-scm.org/D8495
Wed, 06 May 2020 10:33:56 -0700 copy: to find copy source, walk parent of revision we're marking copies in stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 10:33:56 -0700] rev 44814
copy: to find copy source, walk parent of revision we're marking copies in As shown in the previous patch, `hg cp --after --at-rev . src dst` fails if `src` is not in `.`. It seems obvious that you should always walk the *parent* of the revision you're marking copies in, but that's not how it was done for the working copy, and I didn't think to change it when marking copies in a non-working-copy commit. This patch fixes that by walking the parent commit instead, but only if we're marking copies for a non-working-copy commit. We need to leave the working-copy code unchanged because it depends on the weird behavior of `workingctx.walk()`. With these changes, there's very little overlap between the working-copy version and the non-working-copy version of `walkpats()`, but I've refrained from cleaning that up on the stable branch. Differential Revision: https://phab.mercurial-scm.org/D8494
Wed, 06 May 2020 11:41:01 -0700 tests: show that `hg cp -A --at-rev .` doesn't work for renames stable
Martin von Zweigbergk <martinvonz@google.com> [Wed, 06 May 2020 11:41:01 -0700] rev 44813
tests: show that `hg cp -A --at-rev .` doesn't work for renames I clearly forgot to implement (and test) support for marking of renames when I added support for marking of copies :( Differential Revision: https://phab.mercurial-scm.org/D8493
Fri, 08 May 2020 01:19:48 +0200 formatting: add missing newline stable
Raphaël Gomès <rgomes@octobus.net> [Fri, 08 May 2020 01:19:48 +0200] rev 44812
formatting: add missing newline Differential Revision: https://phab.mercurial-scm.org/D8509
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 +3000 tip