Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:47:55 +0100] rev 50069
win32text: drop the `changing_parents` context in revert upgrade
We are not changing parents here, so let us not pretend we do.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 00:29:39 +0100] rev 50068
win32text: clean up and clarify the post-revert hack of dirstate
The change is unrelated to changing parents and should not be a in a
"changing_parents" context. This call is quite hacky, but now it is at least
explicitly hacky.
We will drop the `changing_parents` context in the next changesets, but we kept
this change simple to help readability.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 00:26:08 +0100] rev 50067
dirstate: introduce a `hacky_extension_update_file` method
See inline documentation for details.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 07 Feb 2023 09:36:35 +0100] rev 50066
mq: properly take the wlock during the full qfold operation
Otherwise the operation could be raced… for unknown result.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 04 Feb 2023 11:46:57 +0100] rev 50065
locking: hold the wlock for the full duration of the "keyword demo"
The risk of racing the demo is low, since it seems to create its own repository
on the fly. However it is clearer and more consistent.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 05 Feb 2023 16:54:26 +0100] rev 50064
locking: grab the wlock before touching the dirstate in `perfdirstatewrite`
If we touch the dirstate, we should hold the `wlock`.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 04:22:19 +0100] rev 50063
locking: take the `wlock` for the full `hg addremove` duration
Otherwise, there is a race condition window between the time we resolve the
file to addremove with the matcher and the time we lock the repo and modify the
dirstate.
For example, the working copy might have been updated away, or purged, and the
matched files would no longer be correct.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 16:26:13 +0100] rev 50062
locking: take the `wlock` for the full `hg forget` duration
Otherwise, there is a race condition window between the time we resolve the
file to forget with the matcher and the time we lock the repo and modify the
dirstate.
For example, the working copy might have been updated away, or purged, and the
matched files would no longer be correct.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 04:22:46 +0100] rev 50061
locking: take the `wlock` for the full `hg remove` duration
Otherwise, there is a race condition window between the time we resolve the
file to remove with the matcher and the time we lock the repo and modify the
dirstate.
For example, the working copy might have been updated away, or purged, and the
matched files would no longer be correct.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 04:21:27 +0100] rev 50060
locking: take the `wlock` for the full `hg add` duration
Otherwise, there is a race condition window between the time we resolve the
file to add with the matcher and the time we lock the repo and modify the
dirstate.
For example, the working copy might have been updated away, or purged, and the
matched files would no longer be correct.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 06 Feb 2023 01:22:01 +0100] rev 50059
dirstate: drop some very fishy looking piece of code
This piece of code is marking the **real** dirstate file as a temporary
transaction file. This means it get deleted on transaction rollback.
This this quite wrong, especially as the comment points out some
`dirstate.pending` motivation and the `.pending` file should already be fully
managed by the transaction.
The only ready I can think of this behavior not having awful results right now
is because other transaction logic restore backed up content above the one that
got wrongfully deleted.
Let us stop doing this anyway, All tests seems happy.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 23:05:18 +0100] rev 50058
dirstate: do not write an empty dirstate just for backup
This will get in the way when we get more strict about holding the lock when
writing the dirstate.
Instead, we simply don't copy dirstate files around if there are None at backup
time.
A couple of tests are impacted they no longer need to backup such "empty"
dirstate.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 22:46:26 +0100] rev 50057
dirstate: pre-indent some of the backup code
This will make the next changeset clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 22:27:24 +0100] rev 50056
debugrebuilddirstate: double check that no transaction is open
Since transaction impact dirstate write, we make sure nobody is trying anything
strange with this internal command.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 22:26:23 +0100] rev 50055
dirstate: explicitly write the dirstate after `debugrebuilddirstate`
I am working on making the dirstate write patterns more predictable. This patch is
part of a small series of similar patches that adds a explicit dirstate write in
a handful of location where the dirstate is updated "a bit in a strange way".
With this explicit write, we are no longer relying on implicite write of the
dirstate on `wlock` release. This make the world a better place.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 22:53:54 +0100] rev 50054
dirstate: explicitly write the dirstate after `keyword` "overwrite"
I am working on making the dirstate write patterns more predictable. This patch is
part of a small series of similar patches that adds a explicit dirstate write in
a handful of location where the dirstate is updated "a bit in a strange way".
With this explicit write, we are no longer relying on implicite write of the
dirstate on `wlock` release. This make the world a better place.