Tue, 21 Feb 2023 22:25:20 +0100 dirstate: introduce a check_invalidated decorator
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:25:20 +0100] rev 50118
dirstate: introduce a check_invalidated decorator This is a common need, so let us consolidate it to simplify the code.
Sun, 19 Feb 2023 03:21:12 +0100 dirstate: warn if dirty when starting an edition
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 03:21:12 +0100] rev 50117
dirstate: warn if dirty when starting an edition The dirstate should be clean before we start changing it. Otherwise we might write unrelated changes. Having a dirty dirstate laying around is also suspicious. This is similar to what we do when opening a new transaction, but this time this affect dirstate changes outside of a transaction.
Tue, 21 Feb 2023 03:22:51 +0100 large-files: make sure we write newly initialized standin file early
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 03:22:51 +0100] rev 50116
large-files: make sure we write newly initialized standin file early Any changing context will have to initialized it before anything else. Not flushing the default (pre-change) content mean we would enter the changing context with a dirty dirstate, which is odd.
Mon, 20 Feb 2023 14:06:15 +0100 dirstate: mark `clear` and `rebuild` as `require_changing_parents`
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 14:06:15 +0100] rev 50115
dirstate: mark `clear` and `rebuild` as `require_changing_parents` Yeah, more scoping!
Mon, 20 Feb 2023 11:37:02 +0100 dirstate: add a comment about the semantic of `dirstate.clear`
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:37:02 +0100] rev 50114
dirstate: add a comment about the semantic of `dirstate.clear` This method is weird, lets flag it as such.
Mon, 20 Feb 2023 14:05:19 +0100 debugrebuildstate: wrap the operation in a `changing_parents` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 14:05:19 +0100] rev 50113
debugrebuildstate: wrap the operation in a `changing_parents` context This ismaybe a "changing_files" case? However this would be the only usage of `rebuild` outside a `changing_parents` context and this is a debug command, so lets not make the code base more complex because of that one command.
Sun, 19 Feb 2023 02:50:46 +0100 strip: use a `changing_parents` context for --keep update
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 02:50:46 +0100] rev 50112
strip: use a `changing_parents` context for --keep update These are now properly scoped. note: it would be neat to reuse this in `hg rollback`.
Sun, 19 Feb 2023 02:47:28 +0100 mq: wrap the dirstate's rebuild in a `changing_parents` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 02:47:28 +0100] rev 50111
mq: wrap the dirstate's rebuild in a `changing_parents` context This code is dealing with `qreshesh` failure. In that case the working copy will be left on the parent of the refreshed patch, so the parents are changing and `changing_parents` make sens.
Mon, 20 Feb 2023 11:37:05 +0100 lfconvert: use a `changing_parents` context to clear the dirstate
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:37:05 +0100] rev 50110
lfconvert: use a `changing_parents` context to clear the dirstate Not sure if this is the right context, but it works and it is consistent with the other usages of `dirstate.clear`.
Mon, 20 Feb 2023 11:57:46 +0100 dirstate: mark the `copy` method as requiring a `changing_any` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:57:46 +0100] rev 50109
dirstate: mark the `copy` method as requiring a `changing_any` context This is used both when changing parents (e.g. merging with rename) and changing files (e.g. running `hg rename`).
Mon, 20 Feb 2023 11:54:10 +0100 dirstate: add a `require_changing_any` decorator
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 11:54:10 +0100] rev 50108
dirstate: add a `require_changing_any` decorator We will need it for a couple of usecase (e.g `dirstate.copy`).
Mon, 20 Feb 2023 12:06:03 +0100 rebase: scope parent change into a changing_parents context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 12:06:03 +0100] rev 50107
rebase: scope parent change into a changing_parents context If we are actually altering the working copy (i.e. we are not in memory), we should properly scope the working copy update.
Sat, 18 Feb 2023 04:10:08 +0100 dirstate: requires being in a `changing_parents` `context to set_parents`
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 04:10:08 +0100] rev 50106
dirstate: requires being in a `changing_parents` `context to set_parents` Enforcing proper operation scoping on all methods that mutate the dirstate will tighten correctness and reduce the risk of bugs. The context to use for this method is obvious, and all code was already compliant ☺
Tue, 21 Feb 2023 00:10:20 +0100 dirstate: invalidate on all exceptions
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 00:10:20 +0100] rev 50105
dirstate: invalidate on all exceptions Previously, we would miss SystemExit, KeyboardInterrupt etc. This "fix" on the bug tested in "test-largefiles-update.t" by preventing the precisely tested situation to happens at all. However this reveal a similar bug with a different timing. I have not been able to deal with that pre-existing bug so far. So I updated the test to point that out.
Tue, 21 Feb 2023 01:09:11 +0100 large-files: prepare a test for more changes
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 01:09:11 +0100] rev 50104
large-files: prepare a test for more changes The behavior around this test is about to change. We update the test to make it more robust and the changes clearer.
Tue, 21 Feb 2023 00:32:40 +0100 large-files: larger "changing_parents" context in mergeupdate override
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 00:32:40 +0100] rev 50103
large-files: larger "changing_parents" context in mergeupdate override This since we are updating the lfdirstate early, it seems reasonable to include the full function in that scope.
Sun, 19 Feb 2023 03:14:44 +0100 large-files: use `hacky_extension_update_file` one more time
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 19 Feb 2023 03:14:44 +0100] rev 50102
large-files: use `hacky_extension_update_file` one more time This override is about merging and can be used in a `changing_parents` context. So lets use the method dedicated to hacky stuff when doing hacky stuff.
Sun, 19 Feb 2023 00:04:53 -0500 typing: disable `signature-mismatch` warnings on a few bytestr functions
Matt Harbison <matt_harbison@yahoo.com> [Sun, 19 Feb 2023 00:04:53 -0500] rev 50101
typing: disable `signature-mismatch` warnings on a few bytestr functions Recent versions of pytype complain about this, but it seems like expected behavior.
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 50100
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 02:39:32 +0100 branching: merge with stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 18 Feb 2023 02:39:32 +0100] rev 50099
branching: merge with stable
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 50098
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 50097
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).
Thu, 16 Feb 2023 14:56:59 +0000 rhg: fix a bug in path_encode
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:56:59 +0000] rev 50096
rhg: fix a bug in path_encode This makes rhg able to access long paths at the root of the tree just fine.
Thu, 16 Feb 2023 14:54:34 +0000 rhg: demonstrate a bug in path_encode
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:54:34 +0000] rev 50095
rhg: demonstrate a bug in path_encode The bug means that long filenames at the root of the tree are encoded incorrectly by rhg, so rhg crashes when trying to access them.
Thu, 16 Feb 2023 14:43:46 +0000 rhg: nicer error message
Arseniy Alekseyev <aalekseyev@janestreet.com> [Thu, 16 Feb 2023 14:43:46 +0000] rev 50094
rhg: nicer error message
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 50093
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™.
Tue, 14 Feb 2023 12:40:59 -0500 typing: add type hints to argument checking functions in cmdutil
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 12:40:59 -0500] rev 50092
typing: add type hints to argument checking functions in cmdutil These might be surprising, since they can take strings instead of bytes. The way `AnyStr` works is that it must be all bytes or all str for any given invocation. The wildcard here will be the `opts` that get passed in- if the type is unknown and defaults to `Any`, there's no enforcement that the dict key type matches the additional args. But a lot of uses should be using `**opts` from the command method, which has a str key. The uses of these methods in this module are now typed because their internals force a specific type, and it can't just be inferred from the caller.
Tue, 14 Feb 2023 15:45:26 -0500 tag: move the prohibition of tagging the `null` rev up to the `wdir()` check
Matt Harbison <matt_harbison@yahoo.com> [Tue, 14 Feb 2023 15:45:26 -0500] rev 50091
tag: move the prohibition of tagging the `null` rev up to the `wdir()` check It makes sense to do these together, and avoid another revision lookup.
Fri, 17 Feb 2023 17:04:41 +0100 branching: merge with default
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 17 Feb 2023 17:04:41 +0100] rev 50090
branching: merge with default the first part of the fix is there
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 50089
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -50 -30 +30 +50 +100 +300 +1000 tip