Tue, 14 Feb 2023 23:05:18 +0100 dirstate: do not write an empty dirstate just for backup
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 23:05:18 +0100] rev 50002
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.
Tue, 14 Feb 2023 22:46:26 +0100 dirstate: pre-indent some of the backup code
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 22:46:26 +0100] rev 50001
dirstate: pre-indent some of the backup code This will make the next changeset clearer.
Tue, 14 Feb 2023 22:27:24 +0100 debugrebuilddirstate: double check that no transaction is open
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 22:27:24 +0100] rev 50000
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.
Tue, 14 Feb 2023 22:26:23 +0100 dirstate: explicitly write the dirstate after `debugrebuilddirstate`
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 22:26:23 +0100] rev 49999
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.
Mon, 13 Feb 2023 22:53:54 +0100 dirstate: explicitly write the dirstate after `keyword` "overwrite"
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 22:53:54 +0100] rev 49998
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.
Mon, 13 Feb 2023 23:33:27 +0100 dirstate: explicitly write the dirstate after `eol` dirstate manipulation
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 23:33:27 +0100] rev 49997
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.
Mon, 13 Feb 2023 23:49:52 +0100 dirstate: explicitly write the dirstate after mq dirstate rebuild
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 13 Feb 2023 23:49:52 +0100] rev 49996
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.
Tue, 14 Feb 2023 20:09:39 +0100 transaction: quietly rollback if no other changes than temporary files
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 20:09:39 +0100] rev 49995
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.
Tue, 14 Feb 2023 20:04:17 +0100 transaction: run abort callback in all cases
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 20:04:17 +0100] rev 49994
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.
Tue, 14 Feb 2023 18:59:04 +0100 transaction: clarify the "quick abort" scenario
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 14 Feb 2023 18:59:04 +0100] rev 49993
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
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 tip