Two hours ago, John Clements wrote:
>
> Add'l data point: I tried messing up the clock manually, by turning
> off NTP, but I was unable to duplicate the bug this way.
NTP is unlikely to be the problem, since the times are saved on the
filesystem, independently of the system time (or clock). And since
Robby says that DrR compares only the time value regardless of being
in the future, then there shouldn't be any problem with that.
(It might, however, lead to problems if there's something that can
change the file's time when it's in the future -- for example, if
compiling the file tries to guarantee that it is not in the future for
the compiled file to be further in time, and if DrR causes this by the
automatic compilation. (This is not a guess about the problem, just
an example of how it could break.))
As for git, it shouldn't lead to times in the future, since unlike
other systems (like svn), it does not have a time stamp for each
file. Instead, the idea is that it only changes files that it touches
and uses the current time. This is why a rebase operation can lead to
a lot of time changes -- since it will undo your commit(s), then
fast-forward the repository, then replay the commits, so you end up
with many files that have the same contents, but a different time.
(And as an unrelated reminder -- if this bothers anyone, I have a
wrapper that properly restores the time for such operations.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
