This is an archive of the discontinued Mercurial Phabricator instance.

Differential D11847

status: keep second-ambiguous mtimes during fixup
ClosedPublic

Authored by marmoute on Dec 2 2021, 2:04 PM.

Details

Reviewers
Alphare
Group Reviewers
hg-reviewers
Commits
rHGca42667c8d26: status: keep second-ambiguous mtimes during fixup
Summary

Now that we support the feature, we can keep "second ambiguous" mtime during the fixup phase.
These are the mtime that would be ambiguous if we did not had sub-second précions.

See the v2 format documentation for details.

Diff Detail

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

Event Timeline

marmoute created this revision.Dec 2 2021, 2:04 PM
Alphare accepted this revision.Dec 3 2021, 5:33 AM
This revision is now accepted and ready to land.Dec 3 2021, 5:33 AM
marmoute added a commit: rHGca42667c8d26: status: keep second-ambiguous mtimes during fixup.Dec 3 2021, 5:44 AM
Closed by commit rHGca42667c8d26: status: keep second-ambiguous mtimes during fixup (authored by marmoute). · Explain Why
This revision was automatically updated to reflect the committed changes.

Revision Contents
Changeset List

PathPackages
Mmercurial/dirstateutils/timestamp.py (11 lines)

Diff 31276

mercurial/dirstateutils/timestamp.py

A modification time is reliable if it is older than "present_time" (or A modification time is reliable if it is older than "present_time" (or
sufficiently in the futur). sufficiently in the futur).
Otherwise a concurrent modification might happens with the same mtime. Otherwise a concurrent modification might happens with the same mtime.
""" """
file_mtime = mtime_of(stat_result) file_mtime = mtime_of(stat_result)
file_second = file_mtime[0] file_second = file_mtime[0]
file_ns = file_mtime[1]
boundary_second = present_mtime[0] boundary_second = present_mtime[0]
boundary_ns = present_mtime[1]
# If the mtime of the ambiguous file is younger (or equal) to the starting # 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 # 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 # will not happen right after with the same mtime and we cannot cache the
# information. # information.
# #
# However is the mtime is far away in the future, this is likely some # However if the mtime is far away in the future, this is likely some
# mismatch between the current clock and previous file system operation. So # mismatch between the current clock and previous file system operation. So
# mtime more than one days in the future are considered fine. # mtime more than one days in the future are considered fine.
if boundary_second <= file_second < (3600 * 24 + boundary_second): if boundary_second == file_second:
if file_ns and boundary_ns:
if file_ns < boundary_ns:
return timestamp((file_second, file_ns, True))
return None
elif boundary_second < file_second < (3600 * 24 + boundary_second):
return None return None
else: else:
return file_mtime return file_mtime