Thu, 16 Feb 2023 17:12:21 +0100 test-hardlink: stop explicitly listing `undo.dirstate`
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 17:12:21 +0100] rev 50083
test-hardlink: stop explicitly listing `undo.dirstate` The files is on its way out.
Thu, 16 Feb 2023 04:04:40 +0100 localrepo: enforce a clean dirstate when the transaction open
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:04:40 +0100] rev 50082
localrepo: enforce a clean dirstate when the transaction open This is important to simplify the backup process. This also seems like a quite reasonable expectation. See inline documentation for details.
Thu, 16 Feb 2023 10:43:22 +0100 dirstate: explicitly backup the datafile
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 10:43:22 +0100] rev 50081
dirstate: explicitly backup the datafile Since the transaction does not know about this file, we need to explicitly mark it for backup before touching it.
Thu, 16 Feb 2023 04:41:38 +0100 mq: write the dirstate before stripping
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 04:41:38 +0100] rev 50080
mq: write the dirstate before stripping I am not certain why it is dirty (probably the `repo.setparent` call a right before. However I know we need it flushed before the repository starts to be stripped.
Thu, 16 Feb 2023 03:08:00 +0100 dirstate: simplify the shelve hack to not go through the disk
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 03:08:00 +0100] rev 50079
dirstate: simplify the shelve hack to not go through the disk We already have the data in memory, so why not simply keep the data in memory? This avoid abusing the `savebackup/restorebackup` logic and will make our life easier.
Thu, 16 Feb 2023 20:33:14 +0100 test: fix the flakyness in test-remotefilelog-local.t stable
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 16 Feb 2023 20:33:14 +0100] rev 50078
test: fix the flakyness in test-remotefilelog-local.t I now get about 80% of my `test-chg` CI run that fails on flakyness in this tests. It turns out this is only ambiguous status that end up doing file download. So… calling status early will do that potential download separately and the calls we scrutinize during that test will be just fine.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 tip