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.

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

dirstate: use the `changing_files` context in the `keyword` demo This is the way.

dirstate: wrap repository change in appropriate context in `test-context` We need the `wlock` (to add files), the `lock` (to commit), a `transaction` (to commit) and a `changing_files` context (to add files). Strictly speaking, we could let the commit take the `lock` and create a `transaction`, but it seems more consistent that way.

dirstate: use wlock and changing_files context in `test-revlog-ancestry` This is the way.

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

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

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

dirstate: use `dirstate.change_files` to scope the change in `rename` This is the way, unless we are not actually touching the working copy. In such cases we don't need to do something.

dirstate: use `dirstate.change_files` to scope the change in `copy` This is the way, unless we are not actually touching the working copy. In such cases we don't need to do something.