Wed, 22 Feb 2023 18:03:18 +0100 transaction: the base of a new test file checking transaction abort issue stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:03:18 +0100] rev 49661
transaction: the base of a new test file checking transaction abort issue See inline documentation for details. See other changesets for actual cases.
Wed, 22 Feb 2023 18:30:47 +0100 setup: support building from an ongoing merge stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 18:30:47 +0100] rev 49660
setup: support building from an ongoing merge Before this change the two parents from the merge would duplicate some command output and modify some others in a way python 3.11 chokes on.
Thu, 16 Feb 2023 11:42:34 +0100 rust: upgrade minimum `rayon` dependency stable
Raphaël Gomès <rgomes@octobus.net> [Thu, 16 Feb 2023 11:42:34 +0100] rev 49659
rust: upgrade minimum `rayon` dependency The 1.6.0 and 1.6.1 releases fixes a soundness issue and a performance issue that are both important to us, since both correctness and performance are paramount in the Rust extensions.
Sat, 18 Feb 2023 01:21:51 +0100 test-chg: use a different log to avoid flakyness stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 01:21:51 +0100] rev 49658
test-chg: use a different log to avoid flakyness The test was deleting the log file to start anew. However a trailing working process might still be alive at this time, and recreate the very same log on exit. We see the trace of such worker in the expected content of server.log (see the trace modified by this patch). This is flaky because we don't know *when* the worker will write to the file and there is a race with the `hg init cached` command. A much simpler and reliable way to start anew without having such race is… to write to a different log file. No reuse → no conflict, no conflict → no race, no race → no flakiness.
Fri, 18 Nov 2022 13:51:40 +0000 dirstate-v2: complain early on docket name collision stable
Arseniy Alekseyev <aalekseyev@janestreet.com> [Fri, 18 Nov 2022 13:51:40 +0000] rev 49657
dirstate-v2: complain early on docket name collision The alternative is that the dirstate gets deleted so the corruption persists and is hard to investigate. This happened to me in tests, where the dirstate names are taken from file, since the file got reverted. I expect this can also happen in prod with non-trivial probability (1/4 billion).
Fri, 17 Feb 2023 16:45:36 +0100 setup: further improve the error path for version retrieval stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 16:45:36 +0100] rev 49656
setup: further improve the error path for version retrieval This is a new take at the problem that 8d390a13474d tried to tackle. There was two issues after that previous improvement: - the 0.0+ version could survive a bit too long and reaching the installer version and staying there. - multiple use case where still failing. So the new code is better at: - always succeeding when running `make local` so that we can bootstrap a local version - no using that fallback outside of `make local` to avoid distribution of version with the buggy version number. The setup.py is a gigantic pile of spaghetti code, to the point where pastafarian pilgrim started knocking at its core. However I refrained from cleaning that up since the more to a `setup.cfg` means this code should be deleted soon™.
Fri, 17 Feb 2023 14:00:39 +0100 dirstate: handle missing backup file on restoration stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 14:00:39 +0100] rev 49655
dirstate: handle missing backup file on restoration This is the stable counter part to e358f6e0e50e. Since 6.4 will stop writing undo.dirstate in some case (actually… at all), a transaction created with 6.4 and recover/rolledback with 6.3 need to work to a certain degreee. This changeset add the necessary bits so that we don't get a traceback from 6..3 in this cases.
Tue, 14 Feb 2023 11:56:02 -0500 tag: disallow tagging the working directory stable
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 11:56:02 -0500] rev 49654
tag: disallow tagging the working directory It's kinda silly, but a clear error message is better than a stacktrace about subscripting `None` when trying to generate the default commit message. I'm surprised that `.revsingle(..).node()` returns None instead of `nodemod.wdirid`, but now there's a test to catch if this changes.
Thu, 16 Feb 2023 20:33:14 +0100 test: fix the flakyness in test-remotefilelog-local.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 20:33:14 +0100] rev 49653
test: fix the flakyness in test-remotefilelog-local.t I now get about 80% of my `test-chg` CI run that fails on flakyness in this tests. It turns out this is only ambiguous status that end up doing file download. So… calling status early will do that potential download separately and the calls we scrutinize during that test will be just fine.
Fri, 03 Feb 2023 12:54:17 +0100 fix: add more information to the debug output stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 03 Feb 2023 12:54:17 +0100] rev 49652
fix: add more information to the debug output The previous debug output did not help to understand which file where fixed in which revision. The new output should cover that.
Fri, 03 Feb 2023 01:07:59 -0500 hgweb: unbyteify the 100-continue check stable
Matt Harbison <matt_harbison@yahoo.com> [Fri, 03 Feb 2023 01:07:59 -0500] rev 49651
hgweb: unbyteify the 100-continue check The environment seems to be `str` or `tuple[int]`, and the same check in `wsgicgi.py` is already `str` based, so I suspect this was wrong. I think what happened here is that the string wasn't `r''` prefixed in 482d6f6dba91 like `wsgicgi.py`, so it got wrongly byteified in 687b865b95ad when converting to byte literals en masse.
Mon, 30 Jan 2023 18:50:11 +0100 setup: treat error output and non-zero return code differently stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Jan 2023 18:50:11 +0100] rev 49650
setup: treat error output and non-zero return code differently Choking on Mercurial's stderr mean armless warning can derails the whole install process. We do like to be able to issue warning to people so we stop considering any stderr is a fatal mistake. This allow us to actually boostrap a version of Mercurial without loosing to many sanity point. For example in case where evolve is not loaded, something that happens when the recorded version is malformatted. Creating a wonderful ouroboros.
Mon, 30 Jan 2023 18:41:59 +0100 setup: make the version computation process more resistant stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 30 Jan 2023 18:41:59 +0100] rev 49649
setup: make the version computation process more resistant The tag fetching might return and empty string¹, from there everything derails quickly. As setup tools becomes more picky about version format we make the whole seems a bit more robust. The resulting version will be obviously weird, but at least it will actually install itself. [1] This is a problem we will address in the next changesets.
Mon, 30 Jan 2023 18:25:11 -0500 bundlerepo: enforce the requirements declared by the underlying repository stable
Matt Harbison <matt_harbison@yahoo.com> [Mon, 30 Jan 2023 18:25:11 -0500] rev 49648
bundlerepo: enforce the requirements declared by the underlying repository Previously, `hg log -r 'bundle()' -R bundle.hg` was failing for me when run from source, complaining about an unknown parent, when the system installed `hg` didn't. Some debugging showed the index was 0 length. It turned out that I didn't have the C extensions compiled, which a simple `hg log -r .` was able to indicate. The problem being that the RequirementError got handled by RepoError, which uses an empty directory as a fallback to process the bundle.
(0) -30000 -10000 -3000 -1000 -300 -100 -14 +14 +100 +300 +1000 tip