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.

dirstate: explicitly write the dirstate after mq dirstate rebuild 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.

transaction: quietly rollback if no other changes than temporary files If no actual change have been made, we don't really need to roll them back. We only have to cleanup some temporary files and it seems reasonable to do that quietly. This will help us to use the transaction in wider context¹ without impacting the user experience. [1] as in Python context managers that lives longer.

transaction: run abort callback in all cases Previously, these possibly important callback were "forgotten" when running a quick rollback. This is now fixed, as the tests shown.

transaction: clarify the "quick abort" scenario Right now, the transaction has a code-pass to do a "quick abort" that skip most¹ (too much) of the logic when the right condition are detected² We are about to improve this logic in multiple aspect. We clarify the code first. The conditional return in `_can_quick_abort` looks a bit weird because we are about to make them more complex very soon. [1] actually too much [2] actually not often enough