##// END OF EJS Templates
update: filter the ambiguous mtime in update directly...
marmoute -
r49203:6dc3dc5e default
parent child Browse files
Show More
@@ -2172,6 +2172,71 b' def _update('
2172 2172 mresult.len((mergestatemod.ACTION_GET,)) if wantfiledata else 0
2173 2173 )
2174 2174 with repo.dirstate.parentchange():
2175 ### Filter Filedata
2176 #
2177 # We gathered "cache" information for the clean file while
2178 # updating them: mtime, size and mode.
2179 #
2180 # At the time this comment is written, they are various issues
2181 # with how we gather the `mode` and `mtime` information (see
2182 # the comment in `batchget`).
2183 #
2184 # We are going to smooth one of this issue here : mtime ambiguity.
2185 #
2186 # i.e. even if the mtime gathered during `batchget` was
2187 # correct[1] a change happening right after it could change the
2188 # content while keeping the same mtime[2].
2189 #
2190 # When we reach the current code, the "on disk" part of the
2191 # update operation is finished. We still assume that no other
2192 # process raced that "on disk" part, but we want to at least
2193 # prevent later file change to alter the content of the file
2194 # right after the update operation. So quickly that the same
2195 # mtime is record for the operation.
2196 # To prevent such ambiguity to happens, we will only keep the
2197 # "file data" for files with mtime that are stricly in the past,
2198 # i.e. whose mtime is strictly lower than the current time.
2199 #
2200 # This protect us from race conditions from operation that could
2201 # run right after this one, especially other Mercurial
2202 # operation that could be waiting for the wlock to touch files
2203 # content and the dirstate.
2204 #
2205 # In an ideal world, we could only get reliable information in
2206 # `getfiledata` (from `getbatch`), however the current approach
2207 # have been a successful compromise since many years.
2208 #
2209 # At the time this comment is written, not using any "cache"
2210 # file data at all here would not be viable. As it would result is
2211 # a very large amount of work (equivalent to the previous `hg
2212 # update` during the next status after an update).
2213 #
2214 # [1] the current code cannot grantee that the `mtime` and
2215 # `mode` are correct, but the result is "okay in practice".
2216 # (see the comment in `batchget`). #
2217 #
2218 # [2] using nano-second precision can greatly help here because
2219 # it makes the "different write with same mtime" issue
2220 # virtually vanish. However, dirstate v1 cannot store such
2221 # precision and a bunch of python-runtime, operating-system and
2222 # filesystem does not provide use with such precision , so we
2223 # have to operate as if it wasn't available.
2224 if getfiledata:
2225 ambiguous_mtime = {}
2226 now = timestamp.get_fs_now(repo.vfs)
2227 if now is None:
2228 # we can't write to the FS, so we won't actually update
2229 # the dirstate content anyway, no need to put cache
2230 # information.
2231 getfiledata = None
2232 else:
2233 now_sec = now[0]
2234 for f, m in pycompat.iteritems(getfiledata):
2235 if m is not None and m[2][0] >= now_sec:
2236 ambiguous_mtime[f] = (m[0], m[1], None)
2237 for f, m in pycompat.iteritems(ambiguous_mtime):
2238 getfiledata[f] = m
2239
2175 2240 repo.setparents(fp1, fp2)
2176 2241 mergestatemod.recordupdates(
2177 2242 repo, mresult.actionsdict, branchmerge, getfiledata
General Comments 0
You need to be logged in to leave comments. Login now