Tue, 14 Feb 2023 00:42:00 +0100 dirstate-guard: remove the usage in `import`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:42:00 +0100] rev 50064
dirstate-guard: remove the usage in `import` It is now redundant with the transaction spawning the same scope.
Tue, 14 Feb 2023 00:39:49 +0100 dirstate-guard: replace a usage in `rebase` with a transaction
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:39:49 +0100] rev 50063
dirstate-guard: replace a usage in `rebase` with a transaction Opening the transaction sooner will provide us with the same benefit.
Tue, 14 Feb 2023 00:31:41 +0100 dirstate-guard: remove usage in `rebase`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:31:41 +0100] rev 50062
dirstate-guard: remove usage in `rebase` Now that the dirstate change and write are clearer, it does not seems we need to use a dirstate-guard here anymore. The transaction already wrap the full operation.
Tue, 14 Feb 2023 00:31:23 +0100 dirstate-guard: remove it usage in `mq`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:31:23 +0100] rev 50061
dirstate-guard: remove it usage in `mq` The code it covered is also covered by a `changing_parents` context.
Thu, 26 Jan 2023 17:46:54 +0100 dirstate: enforce the use of `changing_files` context to change tracking
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 17:46:54 +0100] rev 50060
dirstate: enforce the use of `changing_files` context to change tracking Now that everything is using the new context, we can start enforcing its usage.
Tue, 13 Dec 2022 03:55:14 +0100 dirstate: warn if we write to the dirstate without holding the wlock
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 03:55:14 +0100] rev 50059
dirstate: warn if we write to the dirstate without holding the wlock Writing the dirstate without holding the wlock can race with other update and overwrite important change. The comment questionning the current state of things was right, we should the `wlock` should always cover the dirstate. (Yes, this is me, agreeing with myself, half a decade later).
Wed, 15 Feb 2023 21:31:37 +0100 dirstate: avoid transaction backup/restore if we do not hold the lock
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 21:31:37 +0100] rev 50058
dirstate: avoid transaction backup/restore if we do not hold the lock Doing overwriting the dirstate content without holding the lock is a recipe for disaster.
Tue, 13 Dec 2022 09:59:22 +0100 dirstate: issue a developer warning on implicit write on wlock release
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 09:59:22 +0100] rev 50057
dirstate: issue a developer warning on implicit write on wlock release Our goal is to get rid of all these to clarify the writing pattern, so it is time to warn about this (and later, forbid it).
Wed, 15 Feb 2023 23:29:04 +0100 status: fix post status invalidation
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:29:04 +0100] rev 50056
status: fix post status invalidation If the dirstate changed under us, we should throw away what we have a reload it, should we not ?
Wed, 15 Feb 2023 23:28:20 +0100 status: fix post status writing
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:28:20 +0100] rev 50055
status: fix post status writing With dirstate-v2, the status process itself might update internal states. So we make sure this get written on disk
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip