You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Greg Hudson <gh...@MIT.EDU> on 2004/07/13 03:45:30 UTC
Re: svn completely looses file modifications due to FAT 2s time
resolution (data loss!!?)
On Mon, 2004-07-12 at 17:14, Ben Reser wrote:
> To prevent this we currently sleep for 1.1 seconds at the end of such
> operations.
No, we sleep until the second counter ticks, plus .1 seconds. (This
isn't necessarily a good idea, in hindsight. If the filesystem is
remotely mounted, I think the server's time is used for the mod time,
not the client's, so the tick of the client's clock isn't terribly
interesting.)
> 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.
Meaningless. The issue is the interval between the end of the last svn
operation and the time of the modification. The amount of time which
has passed since then is irrelevant.
> c) Keep track of the oldest timestamp we write into the entries file.
The oldest? Surely you mean the newest.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn completely looses file modifications due to FAT 2s time resolution (data loss!!?)
Posted by Ben Reser <br...@siaer.com>.
On Mon, Jul 12, 2004 at 11:45:30PM -0400, Greg Hudson wrote:
> On Mon, 2004-07-12 at 17:14, Ben Reser wrote:
> > To prevent this we currently sleep for 1.1 seconds at the end of such
> > operations.
>
> No, we sleep until the second counter ticks, plus .1 seconds. (This
> isn't necessarily a good idea, in hindsight. If the filesystem is
> remotely mounted, I think the server's time is used for the mod time,
> not the client's, so the tick of the client's clock isn't terribly
> interesting.)
Err yeah right. I knew that.
> > 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.
>
> Meaningless. The issue is the interval between the end of the last svn
> operation and the time of the modification. The amount of time which
> has passed since then is irrelevant.
Yup.
> > c) Keep track of the oldest timestamp we write into the entries file.
>
> The oldest? Surely you mean the newest.
Yes that's what I meant.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org