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

Re: Svn 1.9 repository 20% bigger than svn 1.8 repository

From: Gert Kello <gert.kello_at_gmail.com>
Date: Fri, 29 Jan 2016 10:00:34 +0200

On 29 January 2016 at 02:40, Philip Martin <philip.martin_at_wandisco.com>
wrote:

> > rep-cache.db files are different, 39.7 MB in 1.9 and 58.4 MB in 1.8
>
> The rep-cache is an SQLite file that contains a map of checksums to
> revisions and if stops working then Subversion will continue to allow
> commits but will do less, or no, deduplication.
>
> You can see how many entries there are with:
>
> sqlite3 repo/db/rep-cache.db "select count(*) from rep_cache order"
>
> You can see the entries with:
>
> sqlite3 repo/db/rep-cache.db "select hash,revision from rep_cache order
> by revision"
>
> I suspect 1.9 will show fewer entries, or many refuse to return any
> results at all if the file is corrupt.
>

You are correct, there are 341378 entries in 1.9 file vs 499837 in 1.8

And the failing de-duplication seems to be reason indeed. I have located
one revision which is 112 MB in 1.9 repository but 15 kB in 1.8 repo. The
commit is "add" (without history) of several files, some binary, some text,
total of 900+ MB. Binary files are zip, xls and xlsx, ~92 MB, text files
txt, xml, csv, ~840 MB

How can I test if the 1.9 has really corrupt sqlite db file? For me it
seems that it still gets updates (i.e. when I bring in new revisions with
svnsync.)

Gert
Received on 2016-01-29 09:00:50 CET

This is an archived mail posted to the Subversion Users mailing list.

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