Peter Samuelson wrote:
>>Yves Bergeron wrote:
>>
>>>Not so quite unusual. I've got through a lot of problems on Windows
>>>where the operation on a working copy are realised with batch files.
>>>In my situation, the modification of a file (that do not change it's
>>>size) was done immediately after a checkout. The working copy was
>>>not seeing the modification.
>
>
> [Julian Foad]
>
>>That's a separate bug. I think I saw recently that somebody was
>>working on it.
>
>
> Sounds like the same issue to me. If something is scripted to update a
> checkout then immediately modify files, such that the timestamp doesn't
> change because the filesystem time resolution is too coarse [*], there
> is no way for subversion to detect the change, short of reading the
> whole file.
>
> [*] I think NTFS has a time resolution of 100 nanoseconds or so, but
> not all filesystems are that way.
>
> I suppose one workaround is for the libsvn_wc code to purposely set the
> timestamp of every changed file to one second in the past. Or use the
> time the client was invoked, which will generally be at least one
> second before it completes.
Or - and this is what it actually does - wait for the time stamps to become
older than "now" before exiting and returning control to a program that might
look at the time stamps. See "svn_sleep_for_timestamps()". The "separate bug"
that I referred to is that it doesn't wait for the correct amount of time on
all file systems. It always waits just over one second, whereas it could wait
much less on some systems and needs to wait 2 seconds on FAT and similar systems.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Feb 19 22:31:18 2006