Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:42:36 +0100] rev 50203
dirstate: enforce change context for hacky_extension_update_file
This was the last method not scoped yet
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 04:00:30 +0100] rev 50202
large-files: use a `changing_files` context when initializing the dirstate
We are obviously mutating the dirstate, so lets scope this mutation.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:20:19 +0100] rev 50201
dirstate: enforce context set_clean and set_possibly_dirty
We don't want them called within a `changing_parents` context, but we still want
them called within a context.
So we update the decorator accordingly
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:35:18 +0100] rev 50200
keyword: wrap dirstate mutation in `changing_files` context
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 03:34:48 +0100] rev 50199
keyword: wrap dirstate mutation in `changing_files` context
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 23:10:02 +0100] rev 50198
dirstate: enforce `running_status` context for calling `status`
Now that the context is working as intended and that the callers are updated.
We can enforce it.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:13:29 +0100] rev 50197
dirstate: have `running_status` warn when exiting with a dirty dirstate
If running_status was started without the lock, all changes should have been
explicitly written (with the lock) or invalidated before exiting the context.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 02:21:27 +0100] rev 50196
dirstate: have `running_status` write the dirstate when holding the lock
This is simple and harmless.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 16:57:10 +0100] rev 50195
dirstate: check that dirstate is clean at the initial context opening
More checking that we are not doing anything weird.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:32:04 +0100] rev 50194
dirstate: start tracking that we are within a `running_status` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:28:08 +0100] rev 50193
dirstate: add documentation about the expectation of `running_status` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 14:55:16 +0100] rev 50192
contrib-perf: use `running_status` in `perf::status`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:16:52 +0100] rev 50191
large-files: also open the context in the subdirstate
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:23:06 +0100] rev 50190
large-files: use `running_status` in `mergeupdate`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:22:44 +0100] rev 50189
large-files: use `running_status` in `scmutiladdremove`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:24:47 +0100] rev 50188
large-files: open the transaction sooner in `scmutiladdremove`
We want it to encompass the status call.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:22:16 +0100] rev 50187
large-files: use `running_status` in `overriderevert`
This is the way
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:21:57 +0100] rev 50186
large-files: use `running_status` in `updatestandinsbymatch`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:19:00 +0100] rev 50185
large-files: wrap reposetup's status in a `running_status` context
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:41:27 +0100] rev 50184
narrow: use `running_status` in `updateworkingcopy`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:26:41 +0100] rev 50183
status: use `running_status` in dirstate status
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:22:57 +0100] rev 50182
status: pre-indent the dirstate status code
This make the next changeset clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:18:07 +0100] rev 50181
dirstate: introduce a (noop) running_status context
Let us start with a simplistic context so we can scope the appropriate code
before adding more logic.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:14:12 +0100] rev 50180
status: invalidate dirstate on LockError
If we cannot take the lock, someone else is modifying the repository. Let us
discard dirstate uncommitted data before exiting the status code.
Having a clean dirstate after such operation seems safer.
Strictly speaking, there is a small behavior change in the following situation:
* process A call `status` outside of the `wlock`
* process B grab the `wlock`
* process A fails to acquires the lock to write status fixup
* process B release the `wlock` *without touching the dirstate*
* process A later grab the `wlock`
* process A can write dirstate update from earlier `status`
However this is a fairly hypothetical situation :
* process A has to be raced
* process B have to not update the dirstate
* process A has to run another *unrelated* operation later.
This seems rare enough to overlook.
I am stating that the two operations in process A has to be unrelated.
Otherwise, collecting status data outside of the lock to use them inside the
lock is racy. Any other process could move things around (eg: the working copy)
making the data collected during status irrelevantor even harmful.
If such code exists, it should be fixed ASAP.