On 29 January 2016 at 11:52, Philip Martin <philip.martin_at_wandisco.com>
wrote:
> > 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"
>
Says "ok"
> 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
>
They are identical up to rev 91450. And then there's a large gap between
revisions 91450 and 155838. 155838 seems to be where new "svnsync" was
started, there's gap of time stamps in revision files.
91450 does not seem to be special in term of sync sequence. About 60
revisions within same minute, previous two in same second, next one 4
seconds later
(How does svnsync work? "find last rev at source and sync up to that" or
"sync while next revision present in source"? If latter then first sync
failed for some reason... If first then it probably ran till completion.
But does it actually matter?)
> deduplication other than a dump/load, but it would be interesting to
> find out why it failed.
Should I look at some svn oog information about the revisions where is
started to fail? Anything special to look for? Or should we assume
"antivirus or something else opened the file so that svnsync was unable to
write it"? The sync for this rev has been executing in the middle of day so
it is possible I tried to peek "how big the repo is at disk".
> Which method did you use to write during sync:
> file, svn or http?
>
file:///
Gert
Received on 2016-01-29 11:43:02 CET