On Tue, May 18, 2010 at 1:20 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> Subversion uses a simple heuristic to determine if a file has
>> changed. It is well documented in the source code but perhaps
>> not so well known:
>>
>> If the size and time stamp of a file is the same as when checking
>> out the file it is immediately considered as unchanged. We had a
>> similar issue where an automatic script failed to commit an updated
>> file.
>>
>> This is most easily resolved by adding a small delay between checking
>> out and performing the modification. We used 2 seconds. You need to
>> wait long enough for your operating system file time stamp to tick
>> one step and on Windows this means about 2 seconds to be sure.
>
> On Windows and most operating systems this depends on the filesystem being
> used.
>
> On NTFS you should never see issues like these as the timestamps have 100
> nanosecond precision. On FAT (including FAT32, but not including the newer
> VFAT) however you *do* see this issue.
> (On linux: Ext3 has 1 second precision and Ext4 has nanosecond precision.
> HFS+ on the mac has 1 second precision)
>
> Subversion tries to compensate for 1 second precision filesystems, but this
> is not guaranteed accurate for network filesystems and systems that use 2
> second precision. (It waits until the time changed to the next second before
> returning from for these commands)
Folks seem to be saying that this is an issue in the SVN client's
working copy filesystem, not the SVN server's repository filesystem.
Is that correct?
What part of this process would be dependent on the filesystem's
timestamp resolution:
1) Check out file n from srcurl rev 1000 to working copy 1, wc1
2) Pull the sole value out of n - an integer
3) Increment the integer
4) Check n back in to srcurl with the increased value to srcurl rev 1001
5) Check out file n from dsturl rev 1000 to a new working directory,
wc2 (dsturl is a mirror of srcurl, but a little older)
6) svn merge from srcurl at rev 1000 into wc2
7) checkin modified wc2 to dsturl
?
I'm guessing it's a matter of step 7 (near the beginning, when a
freshness check is applied to n) seeing the same mtime and file size
on file n as it had in step 5 (near the end, when n is written). Is
that correct?
Thanks!
Received on 2010-05-19 18:25:45 CEST