>> -----Original Message-----
>> From: Gavin Lambert [mailto:gavinl@compacsort.com]
>> Sent: Tuesday, February 13, 2007 3:26 PM
>> To: 'Phillip Susi'; 'Ryan Schmidt'
>> Cc: users@subversion.tigris.org
>> Subject: RE: Poor performance in windows. Switching back to CVS
>>
>> Quoth Phillip Susi <mailto:psusi@cfl.rr.com>:
>> > If the timestamps get messed up ( and I used to see this
>> > frequently on windows ) then all the files must be read in
>> > full, causing the process to slow to a crawl. An svn cleanup
>> > should fix that.
>>
>> Actually, on that note: if the OP has their working copy on a FAT/FAT32
>> drive then this could cause problems. FAT only stores filestamps with a
>> 2-second resolution, so unless software that compares timestamps knows
>> that and specifically ignores one-second differences in the timestamp
>> then they'll think the files have changed even when they haven't, which
>> in SVN's case would lead to performance loss as it needs to rescan the
>> contents of each affected file.
>>
>> I don't know if SVN ignores one-second differences in timestamps or not,
>> so I don't know if it's vulnerable to this.
If they are using FAT and long file names the problem is significantly worse
than the time stamp. Long file names use multiple directory entries per
name, the number depends on the length of the name. Not only can you get
file fragmentation but you can get file name fragmentation as well. As files
with different lengths names are deleted and created the names become
interleaved and the pieces of the name can get rather far apart possible in
a different block...
Theoretically you can end up traversing the entire directory listing just to
get a single file name.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Feb 14 09:20:51 2007