[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn completely looses file modifications due to FAT 2s time resolution (data loss!!?)

From: Jon Foster <jon_at_jon-foster.co.uk>
Date: 2004-07-13 00:30:51 CEST

Hi,

Ben Reser wrote:

> b) Drop the sleep. Make the code that checks if a file is changed not
> accept that a file is unchanged without comparing the files when the
> timestamp of the file is within a certain range of the current time.

How does this help? It detects & fixes the test script, which does
something like this:

12:00:01.50: svn up foo ->timestamp of foo is 12:00:02
12:00:01.75: echo change > foo ->timestamp of foo is still 12:00:02
12:00:02.00: svn ci foo ->within 5 seconds, notices change

But this (more realistic?) example fails:

12:00:01.50: svn up foo ->timestamp of foo is 12:00:02
12:00:01.75: echo change > foo ->timestamp of foo is still 12:00:02
... user goes away and does something else ...
12:30:00.00: svn ci foo ->outside 5 seconds, does not notice change

Incidentally, I agree with all your reasons why this is not worth fixing.
I have the misfortune to use "cons" (a "make" replacement) at work. Make
(theoretically) has similar problems with timestamps. The "solution" "cons"
chose was to ignore timestamps and always MD5 every file to see if it's
changed. This is incredibly slow. Bearing in mind programmer's salaries,
I think "upgrade to a decent file system" is a far more cost-effective
solution.

One thing that might be worthwhile is to have the sleep time configurable
in the config file (if it isn't already). That way Windows users can have
it set to 2.1sec by default, and everyone with sane systems (Windows users
with NTFS included) can set it to 100msec or less.

Kind regards,

Jon Foster

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 13 00:31:16 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.