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

RE: Tags and scalability (was Re: Enlightenment)

From: Kean Johnston <jkj_at_caldera.com>
Date: 2002-09-27 21:02:52 CEST

> > 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
(is that the right work for moving to subversion? :). 11 minutes is

I think the scheme proposed of having a read-only get, and then an svn
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
on each file to determine whats changed. But doesn't that happen
I havenbt looked at the code but doesn't subversion need to stat BOTH
right now ... the cached copy and the working copy, to see whats
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
rely solely on filesystem properties. Unless subversion is currently
doing a diff betweeen the cached and working copy, then moving to a
check wont be any less functional than things currently are.


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

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.