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 50164
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 50163
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 50162
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 50161
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 50160
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 50159
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 50158
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 50157
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 50156
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 50155
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 50154
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 50153
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.
(0) -30000 -10000 -3000 -1000 -300 -100 -12 +12 +100 +300 +1000 tip