On Friday 03 December 2004 10:43, Simon Large wrote:
> Ph. Marek wrote:
> > 1) There's some documentation on microsoft (which I couldn't find ATM)
> > regarding the granularity with which timestamps are updated on disk.
> > I remember that being about 30 seconds or such like for FAT.
>
> Timestamps have 2 second resolution on FAT.
They have 2 second resolution, but are written *to disk* only every 30 seconds
or some such.
And we have seen that concurrent processes did *not* see updated timestamps
immediately.
> > 2) We've had the problem a few times that modifications do not show
> > up with concurrent processes. I.e. process "notepad" writes a file,
> > quits, and process "svn" (which is alerted on notepad's exit) tests
> > the file and finds the old timestamp/size - a few seconds later it
> > would find the correct info.
>
> We are only talking about timestamp granularity; the file size should
> still be updated even if the timestamp is 1.9999 seconds too early. And
> in any case, the symptom here would be all or nothing. It can't explain
> a truncated log message.
As far as I understood, it's possible that svn got an empty log file and
therefore refused to commit. Is that wrong?
Maybe notepad or a virus scanner had the log message locked and svn could not
read it ...
Regards,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 3 11:20:09 2004