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

Re: svn update select(2)

From: Larry McVoy <lm_at_bitmover.com>
Date: Mon, 22 Nov 2010 09:27:46 -0800

On Mon, Nov 22, 2010 at 09:35:12AM -0500, C. Michael Pilato wrote:
> On 11/21/2010 07:59 PM, Greg Stein wrote:
> > Hey Larry!
> >
> > Good to hear from you. Been quite a while :-P
> >
> > Yes, the delay is there to deal with filesystem timestamp resolution
> > issues. I don't recall the specifics of *why*, but Bad Things can
> > happen if a filesystem doesn't have enough resolution.
> It has to do with our timestamp-based mod detection. On systems with
> insufficient granularity, it's easy (via operations done in quick
> succession) to get the WC-stored last-known-unmodified timestamp to match
> the timestamp of a quite-modified working file, which causes Subversion to
> not notice that the file is modified.

Huh. So the problem is that svn uses timestamps for modification detection?
That's going to be fast but inaccurate even with your one second sleep.
Think NFS - the server sets the timestamp on creation, client sets it on
modification. So an out of sync (time wise) server and an editor that
unlinks/writes will hose you.

But good to understand the reasoning, that helps, and yes, with the var
things are speedy again.

Thanks for your help, pretty pleasant of you guys.


Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com
Received on 2010-11-22 18:28:25 CET

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.