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 48439
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 48438
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 48437
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
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -3 +3 +10 +30 +100 +300 +1000 +3000 tip