[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: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2005-06-29 23:09:35 CEST

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.

990 files will get stated and timestamps are different. So the files get
detranslated. Sizes of text-base and detranslated files are the same, so a
comparison is forced.

If we had wc-size in .svn/entries, we'd find that sizes are the same. BUT,
we'd still have to detranslate and compare to be sure the files are not

For the ten modified files, wc-size would avoid the

If 990 files were modified, you're right ofcourse.

It's hot and late and I've many things in my head, so please explain what
I'm missing:-)


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jun 29 23:11:20 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.