spectral added a comment.

  In https://phab.mercurial-scm.org/D2729#45664, @indygreg wrote:
  > 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 
  If the user does an `mv` in the shell, at least on Linux, it preserves mtime. 
 If they do a `cp`, it doesn't (the file gets the current timestamp).  This 
includes when overwriting a file.  I think I'd be fine with mimicking this 
behavior (only preserve mtime on `hg mv`) if that would make this safer or 
easier to reason about.
  > 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.
  `hg mv` and `hg cp` require `--after` if the destination file already exists; 
in those cases, we don't seem to touch the working directory at all (including 
not modifying the mtime, even with my patch).  With `--after`, this is purely a 
VCS operation that afaict "shouldn't" have any effect on build systems, so I 
think we're safe here for that concern?
  > 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).

  rHG Mercurial


To: spectral, #hg-reviewers, durin42
Cc: indygreg, durin42, mercurial-devel
Mercurial-devel mailing list

Reply via email to