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
modified.
For the ten modified files, wc-size would avoid the
detranslation/comparison.
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:-)
Best,
//Peter
---------------------------------------------------------------------
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