Am 06.12.2010 13:18, schrieb Ulrich Eckhardt:
On Saturday 04 December 2010, Antoine Pitrou wrote:
Perhaps SVN doesn't get timestamps right.
SVN doesn't touch timestamps explicitly, it just writes the files as they come and the system gives them the timestamps. This also makes sense, because the build system depends on them - you don't want the build to skip compiling files after rewinding your working copy to an older version.
That said, you can tell SVN to do something with timestamps, I'd have to search a bit in order to find out what exactly that is.
What you can ask it to is to use commit times. As you say, this is risky because it may cause build steps to be skipped.
What I'm asking for is that the version control gives the files new time stamps, but still imposes a timestamp order, at least on modern file systems (and, as an option, also on old ones).
Suppose you do an update spanning 20 revisions. The update should: 1. get the current time T at the beginning of the update 2. fetch all files, and update the contents 3. Touch all files, in the order of the revisions, using microsecond steps (i.e. the oldest file gets T, the next revision T+1µs, the next one T+2µs). As the update probably takes longer than 20µs, all files will have timestamps in the past when the update is done.
If the file system does not support subsecond timestamps, you can do the same in second resolution, but that might give you files dated in the future (which make complains about - but you'ld get over with that after 20s). ms might offer some middle ground (but I think all filesystems supporting ms resolution will also support µs).