##// END OF EJS Templates
status: move the boundary comparison logic within the timestamp module...
marmoute -
r49218:aa8a649a default draft
parent child Browse files
Show More
@@ -1823,29 +1823,12 b' class workingctx(committablectx):'
1823 s = self[f].lstat()
1823 s = self[f].lstat()
1824 mode = s.st_mode
1824 mode = s.st_mode
1825 size = s.st_size
1825 size = s.st_size
1826 file_mtime = timestamp.mtime_of(s)
1826 file_mtime = timestamp.reliable_mtime_of(s, mtime_boundary)
1827 cache_info = (mode, size, file_mtime)
1827 if file_mtime is not None:
1828
1828 cache_info = (mode, size, file_mtime)
1829 file_second = file_mtime[0]
1829 fixup.append((f, cache_info))
1830 boundary_second = mtime_boundary[0]
1830 else:
1831 # If the mtime of the ambiguous file is younger (or equal)
1832 # to the starting point of the `status` walk, we cannot
1833 # garantee that another, racy, write will not happen right
1834 # after with the same mtime and we cannot cache the
1835 # information.
1836 #
1837 # However is the mtime is far away in the future, this is
1838 # likely some mismatch between the current clock and
1839 # previous file system operation. So mtime more than one days
1840 # in the future are considered fine.
1841 if (
1842 boundary_second
1843 <= file_second
1844 < (3600 * 24 + boundary_second)
1845 ):
1846 clean.append(f)
1831 clean.append(f)
1847 else:
1848 fixup.append((f, cache_info))
1849 except (IOError, OSError):
1832 except (IOError, OSError):
1850 # A file become inaccessible in between? Mark it as deleted,
1833 # A file become inaccessible in between? Mark it as deleted,
1851 # matching dirstate behavior (issue5584).
1834 # matching dirstate behavior (issue5584).
@@ -99,3 +99,28 b' def mtime_of(stat_result):'
99 subsec_nanos = nanos % billion
99 subsec_nanos = nanos % billion
100
100
101 return timestamp((secs, subsec_nanos))
101 return timestamp((secs, subsec_nanos))
102
103
104 def reliable_mtime_of(stat_result, present_mtime):
105 """same as `mtime_of`, but return None if the date might be ambiguous
106
107 A modification time is reliable if it is older than "present_time" (or
108 sufficiently in the futur).
109
110 Otherwise a concurrent modification might happens with the same mtime.
111 """
112 file_mtime = mtime_of(stat_result)
113 file_second = file_mtime[0]
114 boundary_second = present_mtime[0]
115 # If the mtime of the ambiguous file is younger (or equal) to the starting
116 # point of the `status` walk, we cannot garantee that another, racy, write
117 # will not happen right after with the same mtime and we cannot cache the
118 # information.
119 #
120 # However is the mtime is far away in the future, this is likely some
121 # mismatch between the current clock and previous file system operation. So
122 # mtime more than one days in the future are considered fine.
123 if boundary_second <= file_second < (3600 * 24 + boundary_second):
124 return None
125 else:
126 return file_mtime
General Comments 0
You need to be logged in to leave comments. Login now