largefiles: link the core dirstate._changing context to the lfdirstate one This will be much cleaner and safer to make sure the two dirstates are in sync. This way, the large-files dirstate will simply inherit the state of the main dirstate, so if the core code does the right thing, the large-files code should be right too.

dirstate: add a context for tracking files change Let us start to use it. We will enforce it later.

dirstate: invalidate the dirstate change on transaction failure If the change context lives inside a transaction, the change are not flushed to disk on exit as this is delegated to the transaction. As a result we should also delegate the part that do cleanup on failure. The issue was caught by tests with other change, but it seems useful to fix this as soon as possible.

dirstate: factor the "changing" context logic out This makes it reusable for other types of changes.

dirstate: introduce a `is_changing_any` property This will embrace other cases than changing parents.

dirstate: rename `pendingparentchange` to `is_changing_parents` This is clearer and more inline witht he other change we did.

dirstate: rename _parentwriters to _changing_level We will have context for changing more than parents, so lets be prepared.

largefiles: remove the `changing_parents` context in `openlfdirstate` This code might run in any kind of change context, we should rely on the higher level context instead of opening our own.

largefiles: remove the second `changing_parents` in `updatelfiles` Now that the `update_file` call have been migrated, we can drop the semantically-wrong `changing_parents` context.

largefiles: remove the first `changing_parents` in `updatelfiles` Now that the `update_file` call have been migrated, we can drop the semantically-wrong `changing_parents` context.

largefiles: use `hacky_extension_update_file` in `updatelfiles` This is what the function is meant for.

largefiles: use `hacky_extension_update_file` in `synclfdirstate` This is what the function is meant for.

largefiles: use `hacky_extension_update_file` in `openlfdirstate` This is what the function is meant for.

win32text: make the hacky call cover more cases Now that I understand what this is doing, It seems like the case for `p1_tracked` were covered by neither the code nor the test. Now the code cover it at least.

win32text: drop the `changing_parents` context in revert upgrade We are not changing parents here, so let us not pretend we do.

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.

dirstate: introduce a `hacky_extension_update_file` method See inline documentation for details.

mq: properly take the wlock during the full qfold operation Otherwise the operation could be raced… for unknown result.

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.

locking: grab the wlock before touching the dirstate in `perfdirstatewrite` If we touch the dirstate, we should hold the `wlock`.

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.

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.

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.

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.

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.

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.

dirstate: pre-indent some of the backup code This will make the next changeset clearer.

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.

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.

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.