Gert Kello <gert.ke...@gmail.com> writes:

> 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.)

Check the index with:

  sqlite3 db/rep-cache.db "pragma integrity_check"

Compare the ordered list:

  sqlite3 db/rep-cache.db "select hash,revision from rep_cache order by 
revision"

with the 1.8 list and you may be able to identify which revisions are
missing from the 1.9 rep-cache.  There isn't any way to fix the missing
deduplication other than a dump/load, but it would be interesting to
find out why it failed.  Which method did you use to write during sync:
file, svn or http?

-- 
Philip Martin
WANdisco

Reply via email to