> 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.
>>> (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. :-)
Hans-Emil
Received on Thu Mar 16 08:15:32 2006