Fri, 19 Nov 2021 03:04:42 +0100 dirstate: remove need_delay logic
Pierre-Yves David <pierre-yves.david@octobus.net> [Fri, 19 Nov 2021 03:04:42 +0100] rev 48392
dirstate: remove need_delay logic Now that allĀ¹ stored mtime are non ambiguous, we no longer need to apply the `need_delay` step. The need delay logic was not great are mtime gathered during longer operation could be ambiguous but younger than the `dirstate.write` call time. So, we don't need that logic anymore and can drop it This make the code much simpler. The code related to the test extension faking the dirstate write is now obsolete and associated test will be migrated as follow up. They currently do not break. [1] except the ones from `hg update`, but `need_delay` no longer help for them either. Differential Revision: https://phab.mercurial-scm.org/D11796
Mon, 25 Oct 2021 11:36:22 +0200 dirstate: remove `lastnormaltime` mechanism
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 25 Oct 2021 11:36:22 +0200] rev 48391
dirstate: remove `lastnormaltime` mechanism This is now redundant with the new, simpler `mtime_boundary` one. Differential Revision: https://phab.mercurial-scm.org/D11795
Thu, 18 Nov 2021 13:12:40 +0100 status: use filesystem time boundary to invalidate racy mtime
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 Nov 2021 13:12:40 +0100] rev 48390
status: use filesystem time boundary to invalidate racy mtime We record the filesystem time at the start of the status walk and use that as a boundary to detect files that might be modified during (or right after) the status run without the mtime allowing that edition to be detected. We currently do this at a second precision. In a later patch, we will use nanosecond precision when available. To cope with "broken" time on the file system where file could be in the future, we also keep mtime for file over one day in the future. See inline comment for details. Large file tests get a bit more confused as we reduce the odds for race condition. As a "side effect", the win32text extension is happy again. Differential Revision: https://phab.mercurial-scm.org/D11794
Thu, 18 Nov 2021 15:00:13 +0100 test: use a different timestamp for the updated file
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 Nov 2021 15:00:13 +0100] rev 48389
test: use a different timestamp for the updated file In the test we want to trigger a write after the underlying dirstate changed. To do so, we need a write. And as we are about to make dirstate update smarter we need to meddle with the script a bit to make sure there will be a write. Differential Revision: https://phab.mercurial-scm.org/D11793
Tue, 23 Nov 2021 03:22:30 +0100 win32text: drop associated dirstate cache information on revert
Pierre-Yves David <pierre-yves.david@octobus.net> [Tue, 23 Nov 2021 03:22:30 +0100] rev 48388
win32text: drop associated dirstate cache information on revert Otherwise the could get size from one version of the file while the on-disk version is still clean but with another size. This fix the previously introduced error. Differential Revision: https://phab.mercurial-scm.org/D11792
Wed, 17 Nov 2021 20:27:27 +0100 dirstate: stop gathering parentfiledata in update_file
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Nov 2021 20:27:27 +0100] rev 48387
dirstate: stop gathering parentfiledata in update_file Gathering information here assume that they are valid cache information for a clean file. It is true most of the time, but not garanteed. Accurate data can still be explicitly provided. We drop the spontaneous and will let the next `hg status` call record actual information. Differential Revision: https://phab.mercurial-scm.org/D11791
Wed, 17 Nov 2021 20:26:33 +0100 dirstate: stop gathering parentfiledata in update_file_p1
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Nov 2021 20:26:33 +0100] rev 48386
dirstate: stop gathering parentfiledata in update_file_p1 Gathering information here assume that they are valid cache information for a clean file. It is true most of the time, but not garanteed. So we drop this and will let the next `hg status` call record actual information. Differential Revision: https://phab.mercurial-scm.org/D11790
Wed, 17 Nov 2021 20:26:14 +0100 dirstate: make it mandatory to provide parentfiledata in `set_clean`
Pierre-Yves David <pierre-yves.david@octobus.net> [Wed, 17 Nov 2021 20:26:14 +0100] rev 48385
dirstate: make it mandatory to provide parentfiledata in `set_clean` Gathering the mode, size and mtime, independently from determining that the file is clean is a race-machine. So we just make these information required arguments. (note that the data is still gathered in a racy way in practice, but at least the API is no longer encouraging it.) Differential Revision: https://phab.mercurial-scm.org/D11789
Mon, 22 Nov 2021 15:58:51 +0100 dirstate: do no use `set_clean` in revert
Pierre-Yves David <pierre-yves.david@octobus.net> [Mon, 22 Nov 2021 15:58:51 +0100] rev 48384
dirstate: do no use `set_clean` in revert The current `set_clean` usage is racy (the file might be modified between its restoration and the `set_clean` call). So we simply leave the file as ambiguous and the next status will fix that. We still have to make sure the copy information is dropped, so we teach dirstate how to do that. The win32txt extension is confused after this because current logic is broken in more location. However this series will ultimately fix that so we "ignore" it for now. Fixing it now is complicated without some extra fix landing later. Differential Revision: https://phab.mercurial-scm.org/D11788
Thu, 18 Nov 2021 22:49:05 +0100 status: adapt the "keyword" extensions to gather stats at lookup time
Pierre-Yves David <pierre-yves.david@octobus.net> [Thu, 18 Nov 2021 22:49:05 +0100] rev 48383
status: adapt the "keyword" extensions to gather stats at lookup time See main core code for details. We don't factor the code in a common function yet, because we will have to adapt a bit more things in the keyword case at the end of the series. Differential Revision: https://phab.mercurial-scm.org/D11787
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip