[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: <kfogel_at_collab.net>
Date: 2004-07-12 17:07:29 CEST

Andy Whitcroft <apw@shadowen.org> writes:
> All this guess sleeping Very Sucky (TM). How about we loop (gently) until
> a temp file we touch in the WC has a newer modification time than any
> committed file? In the normal case where the user has typed 'vi' ... 'svn
> commit' we should succeed at the first attempt with 0s delay as enough time
> will already have passed. Otherwise we will have to 'wait' until the timer
> moves on. I am guessing we are returned an apr_time_t here, that is a
> sub-second resolution timer and presumably contains such information for
> OS's which support sexy stat calls. So I guess the loop could retry say
> 10th second or something. Anyhow, this algorithm should 'guarentee' we
> never hit this issue again with any new (older) FS which is even more pants
> timewise?

This sounds interesting. The only issue is that if there are very
many committed files, then the amount of time to inspect them could be
large. In other words, right now we have an O(1) algorithm with a
high constant factor. This change would take us to an O(N) algorithm,
but with a low constant factor.

Sleeping also has the advantage of simplicity.

Are there any OS's with > 2 seconds granularity, but on which
Subversion can run?

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 12 18:36:08 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.