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

Re: TSVNCache cache?

From: Thomas Hruska <thruska_at_cubiclesoft.com>
Date: 2006-03-16 23:18:06 CET

Hans-Emil Skogh wrote:
>> I actually mean something more like a _constant_ cache where TSVNCache
>> uses the .svn folders to manage its own cache. Then it only has to look
>> at the top-level .svn folder of a sub-directory and know what icon
>> overlay to display.
>
> I do not really see how this would be benificial. (Except maybe if you have an urgent lack of RAM.) It will (hopefully :-) ) always be faster to have the information in memory instead of on disk.
> I think that (in theory at least) the current approach should be optimal.

It isn't though. Whenever TSVNCache enters that directory, it
completely stalls Explorer. I've already had one "Open..." dialog
completely freeze an application I use the moment I entered the main
directory (waited about 5 minutes and then force killed the app. from
Task Manager - I assume I hit some sort of deadlock between Explorer,
the application, and TSVNCache).

I have 2GB RAM (at least 512MB is always free), a 3GHz hyperthreaded CPU
(Intel), and several hundred GB of free HD space. System resources are
not a problem for me. If Stefan wants to chew up more hard drive
space/RAM to speed up the cache, I'm all for it (TSVNCache can have up
to 50MB RAM and 2GB HD and I won't care).

>>>> (BTW, my TSVN database is now 626MB...70 revisions. A few
>>>> more revisions and it probably won't fit on a CD).
>>> Wow! That's almost 10MB per revision! May I ask what kind of
>>> files you have under version control that takes so much space?
>> A wide variety of text and binary files (mostly text files and a lot of
>> source code files). There is almost 17 years of programming-related
>> stuff that has never been under version control before
>
> IC. Well, then you should not expect your repository to grow very rapidly from now on. Revistions of source code are saved fairly optimal. The initial import will take the full space, as I don't think that subversion does any compression of the content in the respository except for the diff-compression between revisions. If you just continue to pour new revisions of existing source into that repos I think you will be able to fit the backup on a CD for way more than just a couple of revisions. :-)

At the rate it was growing before the recent additions, it was something
like 50MB at 30 revisions in 3 months for one application. I expect
that rate to increase quite a bit now that my entire source code tree is
under version control. (Just wait until I add my documentation tree...)

BTW, the initial import appears to be compressed. The actual size of
the original data is something along the lines of 3GB.

--
Thomas Hruska
CubicleSoft President
Ph: 517-803-4197
Safe C++ Design Principles (First Edition)
Learn how to write memory leak-free, secure,
portable, and user-friendly software.
Learn more and view a sample chapter:
http://www.CubicleSoft.com/SafeCPPDesign/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Thu Mar 16 23:18:29 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.