( )⚙ D11799 status: move the boundary comparison logic within the timestamp module

This is an archive of the discontinued Mercurial Phabricator instance.

Differential D11799

status: move the boundary comparison logic within the timestamp module
ClosedPublic

Authored by marmoute on Nov 24 2021, 6:13 AM.

Details

Reviewers
Alphare
Group Reviewers
hg-reviewers
Commits
rHG9ae0353c9f5d: status: move the boundary comparison logic within the timestamp module
rHGaa8a649abe10: status: move the boundary comparison logic within the timestamp module
Summary

Some extensions will need it too. So lets isolate the logic. It also makes
things clearer.

Diff Detail

Repository
rHG Mercurial
Branch
default
Lint
No Linters Available
Unit
No Unit Test Coverage

Revision Contents
Changeset List

Diff 31232

mercurial/context.py

): ):
modified.append(f) modified.append(f)
elif mtime_boundary is None: elif mtime_boundary is None:
clean.append(f) clean.append(f)
else: else:
s = self[f].lstat() s = self[f].lstat()
mode = s.st_mode mode = s.st_mode
size = s.st_size size = s.st_size
file_mtime = timestamp.mtime_of(s) file_mtime = timestamp.reliable_mtime_of(s, mtime_boundary)
if file_mtime is not None:
cache_info = (mode, size, file_mtime) cache_info = (mode, size, file_mtime)
file_second = file_mtime[0]
boundary_second = mtime_boundary[0]
# If the mtime of the ambiguous file is younger (or equal)
# to the starting point of the `status` walk, we cannot
# garantee that another, racy, write will not happen right
# after with the same mtime and we cannot cache the
# information.
#
# However is the mtime is far away in the future, this is
# likely some mismatch between the current clock and
# previous file system operation. So mtime more than one days
# in the future are considered fine.
if (
boundary_second
<= file_second
< (3600 * 24 + boundary_second)
):
clean.append(f)
else:
fixup.append((f, cache_info)) fixup.append((f, cache_info))
else:
clean.append(f)
except (IOError, OSError): except (IOError, OSError):
# A file become inaccessible in between? Mark it as deleted, # A file become inaccessible in between? Mark it as deleted,
# matching dirstate behavior (issue5584). # matching dirstate behavior (issue5584).
# The dirstate has more complex behavior around whether a # The dirstate has more complex behavior around whether a
# missing file matches a directory, etc, but we don't need to # missing file matches a directory, etc, but we don't need to
# bother with that: if f has made it to this point, we're sure # bother with that: if f has made it to this point, we're sure
# it's in the dirstate. # it's in the dirstate.
deleted.append(f) deleted.append(f)

mercurial/dirstateutils/timestamp.py

subsec_nanos = 0 subsec_nanos = 0
else: else:
billion = int(1e9) billion = int(1e9)
secs = nanos // billion secs = nanos // billion
subsec_nanos = nanos % billion subsec_nanos = nanos % billion
return timestamp((secs, subsec_nanos)) return timestamp((secs, subsec_nanos))
def reliable_mtime_of(stat_result, present_mtime):
"""same as `mtime_of`, but return None if the date might be ambiguous
A modification time is reliable if it is older than "present_time" (or
sufficiently in the futur).
Otherwise a concurrent modification might happens with the same mtime.
"""
file_mtime = mtime_of(stat_result)
file_second = file_mtime[0]
boundary_second = present_mtime[0]
# If the mtime of the ambiguous file is younger (or equal) to the starting
# point of the `status` walk, we cannot garantee that another, racy, write
# will not happen right after with the same mtime and we cannot cache the
# information.
#
# However is the mtime is far away in the future, this is likely some
# mismatch between the current clock and previous file system operation. So
# mtime more than one days in the future are considered fine.
if boundary_second <= file_second < (3600 * 24 + boundary_second):
return None
else:
return file_mtime