Re: Best practise for long term repository size management

cmpilato@collab.net wrote:

>Daniel Patterson <danpat@adaptiveinternational.com> writes:
>
>
>
>>On Wed, 2003-05-14 at 00:48, kfogel@collab.net wrote:
>>
>>
>>>I just want to echo Francois' point. Your problem is most likely the
>>>Berkeley log files, not the data itself.
>>>
>>>The BDB program is `db_archive', read about it in the sleepcat docs.
>>>
>>>
>>Yes, I'm already doing that. Logfiles aren't really a concern, (they're
>>being archived and stored offline), it's the "strings" database file
>>that's growing at the 20M/day rate. Given that there is no way to
>>shrink that file, or give it an upper bound, what's the best approach to
>>manage it's size?
>>
>>
>
>Switch to RTF instead of native Word docs? At least you have a
>fighting chance of worthwhile deltification. :-)
>
>
Nonsense. You won't get much better deltification from RTF than from
.doc, especially since RFT is much larger to begin with. I just ran a
test (vdelta-test -q, to be precise), comparing two versions of a word
file, between which most of the changes were images (the file contains a
_lot_ of bitmaps).

Here are the results:

    version 1 size: 1.55 MiB
    version 2 size: 1.6 MiB
    delta estimate: 440 kiB (17 windows)

Now, the same files saved as RTF:

    version 1 size: 36.4 MiB
    version 2 size: 40.7 MiB
    delta estimate: 3.0 MiB (417 windows)

3 megs vs. 440k is indeed a great improvement, don't you think? "Big is
beautiful", etc.

Now, maybe my example wasn't very good, given that the files contain
many bitmaps. So I tried the same with a file that contains only one
bitmap, and the only changes between the two versions were review
comments. The file is also a lot smaller.

DOC:

    version 1 size: 170.5 kiB
    version 2 size: 236.0 kiB
    delta estimate: 43.9 kiB (3 windows)

RTF:

    version 1 size: 430.6 kiB
    version 2 size: 492.9 kiB
    delta estimate: 16.7 kiB (5 windows)

Indeed, that's a lot better. However, take into account the fact that
the HEAD version is always stored in full, and you get 279k vs. 508k for
storing two versions of the file, and the break-equal point is around
version 10.

-- 
Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org