On Wed, 2005-03-16 at 12:46 -0500, mike south wrote:
> David Ripton wrote:
> > On 2005.03.16 01:46:12 +0000, mike south wrote:
> > > You don't have to fiddle with mtimes to cause buggy behavior--all you
> > > have to do is have a machine making the modifications, and it's going to
> > > get the commit and then the subsequent modification done inside of the
> > > same second a high percentage of the time. The test code I posted gave
> > > me 2 errors out of four tries.
> >
> > This assumes that file timestamps only have one-second granularity.
> >
> > I don't think the design intent of svn is to only support one-second
> > precision, since it uses apr_time_t with microsecond precision.
> >
> > I suspect that the results you're seeing are due to a svn or apr bug, or
> > a filesystem with low-resolution timestamps. What filesystem and OS are
> > you using?
>
> os is redhat enterprise 3. These are (I think) IBM blades.
>
> Once people started posting about it I did some more testing and learned
> that on the local disk (ext3 fs), I can't get it to happen.
>
> We have shared space on a netapp which is nfs mounted. That is where I
> am seeing the problem. The script I posted will fairly frequently
> create a file that subersion doesn't recognize as being locally modified.
>
NFS is known to have "issues" with timestamps.
In addition, you have to be sure your clocks are synchronized with that
of the nfs server, or else you run into fun issues where people can
create files that appear to be in the future on your machine.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Mar 16 19:53:14 2005