On 6/26/05, Carl Karsten <firstname.lastname@example.org> wrote:
> Erik Huelsmann wrote:
> > Several weeks ago I asked CarlFK on IRC (#svn) to set up Win32 breakage
> > tests on several other Windows flavors than the one sussman's system is
> > running (W2k to be exact).
> > He set up a machine testing on NTFS, which has been running its tests just
> > fine, after initial startup problems. The other system (V400) has been
> > running tests on FAT. This system has been failing the testsuite from the
> > beginning and we haven't been able to fix it since. After a lot of fiddling
> > with the system, I decided to verify testing on FAT with sussman's system.
> > After switching sussman's testsystem to FAT, it started failing lots of
> > tests. From the logs, I conclude that status incorrectly reports files as
> > unchanged. Checking manually with TSVN, I see the same. 'touch'-ing the file
> > turns it into a 'changed' status.
> > What we have here is the problem that FAT has a 2 second timestamp
> > resolution, whereas we only 'sleep-for-timestamps' for 1 second.
> > Conclusion: We're currently broken for use on FAT.
> How does this effect use in the real world? My guess is the failure is due to the
> automated test: update/sleep/check, which wouldn't happen in the real world.
> Keep in mind I don't know why/what is sleeping, but... Could the time stamp check
> adjust one side of the comparison by 2 or 4 seconds? This would cause a false
> positive (i guess) which I also guess would cause un needed updates, but I bet it
> would be A) very rare, and B) may be the only solution.
Subversion uses a changed-detection heuristic based heavily on the
timestamp of the file. To be able to detect changes made to files
immediately after the client exits , it waits a second after some
operation, hoping that enough time has passed so the changes lead to
a new timestamp. On FAT this won't work, because the second is too
short: it has a 2sec resolution.
> Carl K
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sun Jun 26 08:50:44 2005