Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 00:33:15 +0100] rev 50128
dirstate-guard: remove the feature
The dirstate guard duplicated some of the logic already implemented in the
transaction (and now the changing_* context).
However the feature was incomplete, for example, living only in memory meant we
could not recover from the hardest crash. In addition this duplicated with the
transaction logic meant things could go out of sync or step on each other.
Removing the feature now that we no longer needs it seems the safest.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 00:14:21 +0100] rev 50127
rollback: remove the dirstateguard usage
Thanks to the previous changeset, we no longer needs it.
begone !
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 10:00:59 +0100] rev 50126
rollback: explicitly skip dirstate rollback when applicable
instead of letting the transaction logic overwrite the dirstate and then
overwrite that overwrite with a backup. We simply do not restore the dirstate
related file during the _playback call.
This open the way to removing the last dirstate guard usage.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 00:26:24 +0100] rev 50125
rollback: detect "parentgone" case earlier
Detecting this earlier will help us to affect the rollback process sooner, which
will help the next changesets.
To keep things simple, we degrade the behavior a bit when the `undo.desc` is
missing. However since `hg rollback` is not supposed to be used and the
`undo.desc` file have been introduced in mercurial 1.6 (2010). I think this is
an acceptable evil.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:39:10 +0100] rev 50124
rollback: avoid a `hg commit --addremove` at a critical point
The rollback behavior around `hg commit --addremove` has changed slightly. It
does not really matters here but keeping that variant out of the way cannot
hurt.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 20:48:51 +0100] rev 50123
rollback: display some graphlog before/after a test piece
This make the situation clearer.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 20:47:08 +0100] rev 50122
rollback: show that the safety works in a associated test
That test section is checking that --force is overcoming the safety check,
however we did not check that the safety properly detect the situation.
We now do for clarity.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:40:27 +0100] rev 50121
dirstate-guard: remove its usage in `backout`
We can simply replace it with a transaction.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:42:00 +0100] rev 50120
dirstate-guard: remove the usage in `import`
It is now redundant with the transaction spawning the same scope.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:39:49 +0100] rev 50119
dirstate-guard: replace a usage in `rebase` with a transaction
Opening the transaction sooner will provide us with the same benefit.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:31:41 +0100] rev 50118
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 00:31:23 +0100] rev 50117
dirstate-guard: remove it usage in `mq`
The code it covered is also covered by a `changing_parents` context.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 26 Jan 2023 17:46:54 +0100] rev 50116
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 03:55:14 +0100] rev 50115
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).
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 21:31:37 +0100] rev 50114
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.
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 13 Dec 2022 09:59:22 +0100] rev 50113
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).
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:29:04 +0100] rev 50112
status: fix post status invalidation
If the dirstate changed under us, we should throw away what we have a reload it,
should we not ?
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 15 Feb 2023 23:28:20 +0100] rev 50111
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
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Dec 2022 02:54:06 +0100] rev 50110
dirstate: use `dirstate.change_files` to scope the change in `shelve`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Dec 2022 03:04:58 +0100] rev 50109
dirstate: use `dirstate.change_files` to scope the change in `unshelve`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 15 Dec 2022 06:22:23 +0100] rev 50108
shelve: adjust what happens in some `changing_parents` context
It seems like the rest is more about changing tracked_files, so we let start
with moving them out of the `changing_parents` contexts.
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 23:29:30 +0100] rev 50107
dirstate: use `dirstate.change_files` to scope the change in `lfconvert`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 05 Feb 2023 12:09:52 +0100] rev 50106
largefiles: rely on main scoping for writing dirstate in `markcommitted`
Yeah, cleaner code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sun, 05 Feb 2023 12:05:23 +0100] rev 50105
largefiles: rely on main scoping for writing dirstate in `mergeupdate`
Yeah, cleaner code.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 04 Feb 2023 16:54:46 +0100] rev 50104
largefiles: rely on the higher level `changing_giles` in `mergerecordupdates`
Now that context open on the main dirstate also affect the underlying one, we
can skip opening our own in `mergerecordupdates`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 14 Dec 2022 00:46:58 +0100] rev 50103
dirstate: use wlock and `dirstate.change_files` to scope the change in `mq`
This is the way.
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 25 Jan 2023 12:51:26 +0100] rev 50102
subrepo: use `changing_files` context in subrepository code
This is better, not ideal, but better.
Pierre-Yves David <pierre-yves.david@octobus.net> [Sat, 04 Feb 2023 12:14:19 +0100] rev 50101
subrepo: let black expand some call on multiple lines early
newer version of black are righfully doing this, so I apply it before more
semantic change to reduce noise in the next changeset.