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.

rollback: remove the dirstateguard usage Thanks to the previous changeset, we no longer needs it. begone !

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.

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.

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.

rollback: display some graphlog before/after a test piece This make the situation clearer.

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.

dirstate-guard: remove its usage in `backout` We can simply replace it with a transaction.

dirstate-guard: remove the usage in `import` It is now redundant with the transaction spawning the same scope.

dirstate-guard: replace a usage in `rebase` with a transaction Opening the transaction sooner will provide us with the same benefit.

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.

dirstate-guard: remove it usage in `mq` The code it covered is also covered by a `changing_parents` context.

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.

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).

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.

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).

status: fix post status invalidation If the dirstate changed under us, we should throw away what we have a reload it, should we not ?

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

dirstate: use `dirstate.change_files` to scope the change in `shelve` This is the way.

dirstate: use `dirstate.change_files` to scope the change in `unshelve` This is the way.

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.

dirstate: use `dirstate.change_files` to scope the change in `lfconvert` This is the way.

largefiles: rely on main scoping for writing dirstate in `markcommitted` Yeah, cleaner code.

largefiles: rely on main scoping for writing dirstate in `mergeupdate` Yeah, cleaner code.

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`

dirstate: use wlock and `dirstate.change_files` to scope the change in `mq` This is the way.

subrepo: use `changing_files` context in subrepository code This is better, not ideal, but better.

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.

dirstate: use `dirstate.change_files` to scope the change in `import` This is the way.

dirstate: use `dirstate.change_files` to scope the change in `automv` This is... mostly... the way.