Mercurial > hg
changeset 50131:e5f5f1c1c452
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.
| author | Pierre-Yves David <pierre-yves.david@octobus.net> |
|---|---|
| date | Tue, 21 Feb 2023 22:14:12 +0100 |
| parents | 9e1debbb477e |
| children | 3dd7e54ff7f1 |
| files | mercurial/context.py |
| diffstat | 1 files changed, 1 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/mercurial/context.py Tue Feb 21 16:20:11 2023 +0100 +++ b/mercurial/context.py Tue Feb 21 22:14:12 2023 +0100 @@ -1889,7 +1889,7 @@ for ps in poststatus: ps(self, status) except error.LockError: - pass + dirstate.invalidate() finally: # Even if the wlock couldn't be grabbed, clear out the list. self._repo.clearpostdsstatus()