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