Re: bug in svn diff and related?

On 2005.03.16 20:44:15 +0000, John Szakmeister wrote:
> On Wednesday 16 March 2005 11:58, Travis P wrote:
> > David,
> >
> > Are you aware of any filesystems that maintain timestamps on files with
> > any finer granularity than 1 second? I believe such would be the
> > exception.
>
> Theoretically, NTFS can support 100ns second resolution. I don't believe
> it does any better than a second in practice though.

XFS and JFS support nanosecond timestamps. So do filesystems like proc
and tmpfs under Linux 2.6, though they don't really count. I agree
that these are exceptions, and that most people still use filesystems
with 1s timestamp resolution.

This appears to not really matter much, because svn works around the
potential problem by sleeping (until the next second, plus a tenth) to
force timestamps to change.

svn_sleep_for_timestamps is not quite ideal, because it assumes file
timestamp resolution is always 1s. FAT has 2s timestamp resolution, so
maybe this isn't quite conservative enough. (Though I haven't tried
reproducing the original poster's problem on FAT, which I'd want to do
before actually claiming this needs fixing.)

The original poster's problem was related to NFS, and went away when he
put the working copy on a local filesystem. I suspect clock skew versus
the NFS server, though that's not confirmed.
 
IMO, the NFS entry in the svn FAQ is too optimistic. I will attempt to
add some caveats to it and send a doc patch.

-- 
David Ripton    dripton@ripton.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org