[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: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-06-29 18:37:09 CEST

"Erik Huelsmann" <e.huelsmann@gmx.net> writes:

>> > It would also greatly increase 'svn st' speed in case filestamps don't
>> > match. In the current scenario, the file must be 'detranslated' to be
>> > able to check its size against the size stored in the .svn/entries
>> > file. Storing the WC file size would eliminate the need for that step
>> > in many situations (ie where a change resulted in a file size change).

That's one of the suggestions in notes/wc-improvements.

>> >
>> 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.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 18:38:06 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.