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. Cheers, -- --- Larry McVoy lm at bitmover.com http://www.bitkeeper.com
