[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion & FAT failures

From: Carl Karsten <carl_at_personnelware.com>
Date: 2005-06-30 00:46:55 CEST

Peter N. Lundblad wrote:
> On Wed, 29 Jun 2005, Philip Martin wrote:
>>"Erik Huelsmann" <e.huelsmann@gmx.net> writes:
>>>>I've been thinking about this, but I'm not sure this will "greatly improve
>>>>svn status" because most files are note modified in a typical situation.
>>>>So, for most files, you'll get equal file sizes and a forced
>>>>byte-by-byte-comparisons. Or do I miss something?
>>>Nope, you're entirely correct.
>>Really? Take something like status, at present every modified file
>>causes the working file to be read/translated. When I use Subversion
>>most of my mods change the file size, so the size check should bypass
>>the need to read/translate those files. The resut should be that
>>status rarely needs to read/translate working files, while at present
>>it needs to read/translate every modified file. That should make a
>>big difference if the files are not cached in memory.
> My assumption is that only a small nuber of files are modified in the
> typical case. Say my WC have 1000 files and I modified 10. Then I put my
> WC on a FAT memory stick so the timestamps get screwed.

I would say the "put on stick" strays from the "typical case." Your assessment of
what does/would happen may be correct, but I don't think this case should drive
svn development.

If the "put on stick" step causes a significant problem, then I would look to some
solutions outside SVN, like using tar to preserve the file attributes. or format
it with an fs other than fat. (yeah, I know... fat is the best fs for sharing
between Win and the rest of the world.)

Carl K

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 30 00:47:34 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.