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.

dirstate: explicitly write the dirstate after `eol` dirstate manipulation 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.