Wed, 22 Feb 2023 00:22:16 +0100 large-files: use `running_status` in `overriderevert`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:22:16 +0100] rev 50138
large-files: use `running_status` in `overriderevert` This is the way
Wed, 22 Feb 2023 00:21:57 +0100 large-files: use `running_status` in `updatestandinsbymatch`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:21:57 +0100] rev 50137
large-files: use `running_status` in `updatestandinsbymatch` This is the way.
Wed, 22 Feb 2023 00:19:00 +0100 large-files: wrap reposetup's status in a `running_status` context
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:19:00 +0100] rev 50136
large-files: wrap reposetup's status in a `running_status` context This is the way.
Wed, 22 Feb 2023 00:41:27 +0100 narrow: use `running_status` in `updateworkingcopy`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:41:27 +0100] rev 50135
narrow: use `running_status` in `updateworkingcopy` This is the way.
Mon, 20 Feb 2023 17:26:41 +0100 status: use `running_status` in dirstate status
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:26:41 +0100] rev 50134
status: use `running_status` in dirstate status This is the way.
Mon, 20 Feb 2023 17:22:57 +0100 status: pre-indent the dirstate status code
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 17:22:57 +0100] rev 50133
status: pre-indent the dirstate status code This make the next changeset clearer.
Mon, 20 Feb 2023 15:18:07 +0100 dirstate: introduce a (noop) running_status context
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 20 Feb 2023 15:18:07 +0100] rev 50132
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.
Tue, 21 Feb 2023 22:14:12 +0100 status: invalidate dirstate on LockError
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:14:12 +0100] rev 50131
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.
Tue, 21 Feb 2023 16:20:11 +0100 status: simplify the post status fixup phases
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 16:20:11 +0100] rev 50130
status: simplify the post status fixup phases With the wlock automatically discarding changes when applicable, we can simplify the code a bit. * we perform the fixup operation before trying to grab the lock to narrow the `try/except` * we no longer need to explicitly complare dirstate identities. We can trust the dirstate internal refresh for that. It would invalidate dirty data when needed. * detect still data invalidation by checking the dirty flag before and after taking the lock. Doing this is actually only necessary to issue the debug message, we could blindy trust the dirstate internal to ignore the `write` call on a non-dirty dirstate.
Tue, 21 Feb 2023 15:35:31 +0100 dirstate: cleanup the `_map` property cache
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 15:35:31 +0100] rev 50129
dirstate: cleanup the `_map` property cache The removed code was duplicating the effect of `@propertycache`. This is a gratuitous cleanup.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip