Thu, 19 May 2022 12:23:38 +0100 rhg: align the dirstate v2 writing algorithm with python stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 19 May 2022 12:23:38 +0100] rev 48867
rhg: align the dirstate v2 writing algorithm with python Use the same algorithm of file append as python does, where we do a manual seek instead of relying on O_APPEND. (see the reasons in the inline comment)
Tue, 17 May 2022 14:59:25 +0100 test-dirstate: actually test the append code path in dirstate v2 stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Tue, 17 May 2022 14:59:25 +0100] rev 48866
test-dirstate: actually test the append code path in dirstate v2 Apparently it's not sufficient to modify a file to force the dirstate write-out, so the append code path was untested. By removing a file instead of changing we're forcing append to happen.
Tue, 17 May 2022 00:09:51 +0100 ci: do not trigger phabricator for merge-request stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 17 May 2022 00:09:51 +0100] rev 48865
ci: do not trigger phabricator for merge-request The fast the phabricator steps has a `rules` entry makes it selected for the special `merge_requests` pipelines. The other ones behave as default and are not selected tot the mrege_request pipelines. This result in a second pipeline to be created, with only the phabricator pipeline in it. Which usually succeed fast (since there is nothing to do). This is harmful as this create a false sense of "the series is passing" and Gitlab will use this simplistic pipeline for validation. By explicitly preventing the pipeline to be created in the merge-request case, we prevent this situation to happens Note that the job will be dropped (alonside phabricator) in the next two weeks anyway.
Wed, 11 May 2022 17:56:29 -0700 amend: stop specifying matcher, get all copies in wctx stable
Kyle Lippincott <spectral@google.com> [Wed, 11 May 2022 17:56:29 -0700] rev 48864
amend: stop specifying matcher, get all copies in wctx When we're recreating the commit that we'll be committing, we don't want to filter our copy information based on just the *new* [versions of the] files we're amending. The test has an example of this case, but for clarity, the situation is: ``` $ hg cp src dst && hg commit <do some work> $ hg amend some_unrelated_file.txt $ hg status --copies A dst A some_unrelated_file.txt ``` What *should* happen is that `dst` should remain marked as a copy of `src`, but this did not previously happen. `matcher` here only includes the files that were specified on the commandline, so it only gets the copy information (if any, in this example there's not) for `some_unrelated_file.txt`. When it goes to apply the memctx to actually create the commit, the file copy information is incomplete and loses the information for the files that shouldn't have been affected at all by the amend. Differential Revision: https://phab.mercurial-scm.org/D12625
Wed, 11 May 2022 17:56:10 -0700 amend: add test showing poor behavior when copies are involved stable
Kyle Lippincott <spectral@google.com> [Wed, 11 May 2022 17:56:10 -0700] rev 48863
amend: add test showing poor behavior when copies are involved Differential Revision: https://phab.mercurial-scm.org/D12624
Wed, 04 May 2022 17:40:23 +0100 censor: fix [hg update] away from a revision with censored files stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Wed, 04 May 2022 17:40:23 +0100] rev 48862
censor: fix [hg update] away from a revision with censored files Differential Revision: https://phab.mercurial-scm.org/D12604
Fri, 22 Apr 2022 14:39:00 +0100 censor: demonstrate a bug stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 22 Apr 2022 14:39:00 +0100] rev 48861
censor: demonstrate a bug Differential Revision: https://phab.mercurial-scm.org/D12584
Wed, 04 May 2022 18:04:46 +0200 Added signature for changeset 0ddd5e1f5f67 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 18:04:46 +0200] rev 48860
Added signature for changeset 0ddd5e1f5f67
Wed, 04 May 2022 18:04:06 +0200 Added tag 6.1.2 for changeset 0ddd5e1f5f67 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 18:04:06 +0200] rev 48859
Added tag 6.1.2 for changeset 0ddd5e1f5f67
Wed, 04 May 2022 18:00:01 +0200 ci: remove py2-rust support stable 6.1.2
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 18:00:01 +0200] rev 48858
ci: remove py2-rust support Nobody cares about this very narrow usecase, and py2 support is over by July 1st. This helps with the CI load, and removes some flakiness.
Wed, 04 May 2022 17:45:20 +0200 relnotes: add release notes for 6.1.2 stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 17:45:20 +0200] rev 48857
relnotes: add release notes for 6.1.2
Tue, 03 May 2022 12:41:21 +0200 docs: use proper rst markup for preformatted blocks stable
Mads Kiilerich <mads@kiilerich.com> [Tue, 03 May 2022 12:41:21 +0200] rev 48856
docs: use proper rst markup for preformatted blocks The multiple lines were re-flowed to a single line, both in man page and html.
Wed, 04 May 2022 15:49:20 +0200 test-dirstate: print something when the check is skipped stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 15:49:20 +0200] rev 48855
test-dirstate: print something when the check is skipped This makes a programming error obvious in cases when it should not be skipped Differential Revision: https://phab.mercurial-scm.org/D12602
Wed, 04 May 2022 15:48:13 +0200 test-dirstate: fix detection of Rust environment variable stable
Raphaël Gomès <rgomes@octobus.net> [Wed, 04 May 2022 15:48:13 +0200] rev 48854
test-dirstate: fix detection of Rust environment variable The Rust path never actually worked. This change also improves clarity of the comment. The next change will ensure we print something when this check fails. Differential Revision: https://phab.mercurial-scm.org/D12601
Thu, 28 Apr 2022 17:15:35 +0200 rust-dirstate-v2: fix the unused bytes counter when rewriting the dirstate stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 17:15:35 +0200] rev 48853
rust-dirstate-v2: fix the unused bytes counter when rewriting the dirstate As per the previous patch, the counter was incorrectly carried over from the old docket when it should be reset for a complete rewrite. Differential Revision: https://phab.mercurial-scm.org/D12594
Thu, 28 Apr 2022 17:11:51 +0200 rust-dirstate-v2: show `unused_bytes` counter is not reset on total rewrite stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 28 Apr 2022 17:11:51 +0200] rev 48852
rust-dirstate-v2: show `unused_bytes` counter is not reset on total rewrite This was picked up by @aalekseyev when doing unrelated debugging. The Rust implementation was never resetting this counter, so a brand new file would carry over the old counter. As I write this, my counter is a supposed 7389089 unused bytes for a total of 170978 bytes in the data file. Feel free to post your own high score. Differential Revision: https://phab.mercurial-scm.org/D12593
(0) -30000 -10000 -3000 -1000 -300 -100 -16 +16 +100 +300 +1000 tip