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.
Wed, 22 Feb 2023 01:08:25 +0100 dirstate: only reload the dirstate when it may have changed
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 01:08:25 +0100] rev 50128
dirstate: only reload the dirstate when it may have changed This reinstall the equivalent of what the `filecache` was doing. However it does it at the dirstate level. There is a double motivation for this: - This avoid duplicating logic with the dirstate "identity" logic. - This increase the lifetime of the `dirstate` object, helping to implement change scoping.
Wed, 22 Feb 2023 01:04:55 +0100 dirstate: directly manage the dirstate property on localrepo
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 01:04:55 +0100] rev 50127
dirstate: directly manage the dirstate property on localrepo Before we had: * the filecache layer on `localrepo` doing some caching * the dirstate having some internal invalidation/refresh machanism * the status code doing some identity validation. To clean this up, we are dropping the first item "localrepo `filecache`" from the equation in a favor of an approach integrated into the dirstate (second item) in the next changesets. This changeset will be a small windows where some things will be a bit slower. This will be fixed in the next changesets.
Tue, 21 Feb 2023 15:10:12 +0100 dirstate: factor the identity getting/setting code in the dirstate map
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 15:10:12 +0100] rev 50126
dirstate: factor the identity getting/setting code in the dirstate map We are doing the same things twice and we will add more logic in the next changesets. So lets start factoring things out now.
Wed, 22 Feb 2023 00:53:51 +0100 dirstate: use `cachestat` object for dirstatemap identity
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 22 Feb 2023 00:53:51 +0100] rev 50125
dirstate: use `cachestat` object for dirstatemap identity There is a class dedicated to this kind of cache check, let us use it. We will generalize this code in the next changesets, but we do the "behavior changing" pass on our own.
Tue, 21 Feb 2023 22:17:33 +0100 automv: lock the repository before searching for renames
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 21 Feb 2023 22:17:33 +0100] rev 50124
automv: lock the repository before searching for renames I detected this while debugging something else.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip