> > Have you considered storing the text-base files compressed?
> It would
> > be pretty easy to implement - you've already got zlib in there - and
> > save quite a bit of disk for only a small speed penalty.
> >
>
> I like that idea. Plus, it only affects libsvn_wc.
Not sure sure how "small" the speed penalty would be. It takes over 11
minutes to compress the tarballs of the repository I am wanting to
subvert
(is that the right work for moving to subversion? :). 11 minutes is
quite
noticable.
I think the scheme proposed of having a read-only get, and then an svn
edit,
is the best way to go. Either that or storing the fileprops and maybe a
CRC or MD5 hash in a data file in .svn. But that would require doing a
stat
on each file to determine whats changed. But doesn't that happen
already?
I havenbt looked at the code but doesn't subversion need to stat BOTH
files
right now ... the cached copy and the working copy, to see whats
changed?
If so, then moving to a single data file with fileprops and then stating
each working copy file for comparison will at least be a 100% savings in
stat calls.
If we don't use an MD5/CRC then we don't even need to open the files, we
can
rely solely on filesystem properties. Unless subversion is currently
actually
doing a diff betweeen the cached and working copy, then moving to a
fileprops
check wont be any less functional than things currently are.
Kean
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Sep 27 21:19:24 2002