Gert Kello <gert.ke...@gmail.com> writes: > 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
The rep-cache failure almost certainly explains the size difference. > (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?) svnsync uses revision properties on r0 that get updated as the sync proceeds: svnlook proplist -v --revprop -r0 path/to/repo > 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". The SQLite code expects there to be contention for the file and has a timeout (10s as I recall). In your case something appears to have blocked access for an extended period of time. -- Philip Martin WANdisco
