kfogel@collab.net wrote:
> "C.A.T.Magic" <c.a.t.magic@gmx.at> writes:
>
>>Hi subversion devs!
>>
>>I already pointed out that the 'sleep_for_timestamps'
>>is a really weak solution and will break for FAT disks,
>>because FAT only records file modifications with
>>a resolution of 2 seconds (and some very strange
>>time-rounding rules... afair).
>>
>>Please look at the small script below,
>>and its output. only the FIRST revision gets committed,
>>even though there should be 5 commited revisions.
>>this means that 4 file modifications are LOST.
>>
>>it works if i put a 'sleep' after each svn commit command.
>
>
> Thank you.
>
> What is a good solution? Perhaps we should sleep for 2 seconds on FAT
> systems?
a)
write a ".svn/dummy" file to disk,
read back its modification time and wait
for that time to pass by.
b)
whenever a relevant wc file gets modified,
stat for its filetime.
then wait for that time to pass by.
AFAIK time always gets rounded to the next
higher possible value, so it should be safe
to 'wait for exactly the filetime' of the
very last modified file.
its NOT neccessary to wait for a filetime
change TWICE.
im also not sure if a single command could
operate on both FAT and NTFS at the same time,
e.g. a "temp" file on a FAT disk getting 'moved'
to an NTFS directory?
also note, that if someone copies a WC from
NTFS/ext3 to FAT, all timestamps get rounded/modified
simultaneously. This means that storing a WC
on a FAT formatted memory stick will probably
mark all the files as modified, or at least
svn will have to verify all the MD5 sums over
and over...
:-)
======
c.a.t.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 12 19:51:21 2004