indygreg added a comment.
I'm sorry, but we cannot ship this as is. The reason is mtime based build systems, like GNU make. We can't have version control modifying files without bumping their mtime because this invalidates the target freshness checks of mtime-based build systems. If we want to preserve mtime on file copy or move, I believe it is safe to do that if and only if the destination file didn't already exist. But if the destination exists, we need to ensure the mtime of the new file is greater than the mtime of the old file. Reading this patch, I /think/ the previous behavior was buggy in edge cases because we never ensured the mtime of the replacement was newer than the existing file. In 99.99% of cases, it will be because the existing file was created sometime in the past. But if bad clocks or other wonky things are in play, there's no guarantee that *wall clock now* is greater than the mtime of the existing destination file. The correct thing to do in this situation is read the mtime of the existing file and ensure the mtime of the new file is at least 1s greater than the previous mtime (1s because not all filesystems preserve microsecond or millisecond mtime granularity). REPOSITORY rHG Mercurial REVISION DETAIL https://phab.mercurial-scm.org/D2729 To: spectral, #hg-reviewers, durin42 Cc: indygreg, durin42, mercurial-devel _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
