I managed to replay only to Philip first, so I have a chance to write
changed/better answer to list :)
> 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.
>
>
The revision file write times:
91448 -> 13:16:44
91449 -> 13:16:44
91450 -> 13:16:44
91451 -> 13:16:48
91452 -> 13:16:48
91452 -> 13:17:00
91450 was the last one that has data is sqlite database.
91451 has nothing in 1.8 db neither
91452 has one entry in 1.8 db.
So the 10 sec timeout is possible. However, I peeked into the event logs;
seems like our server is logging all process starts/ends. I see that at
13:16:48, cmd.exe process was started. 13:16:49 a wermgr.exe is started -
its windows error reporting tool. And 13:16.50 a rundll32.exe is started.
The wermgr.exe ends at 13:16.50 and rundll32.exe at 13.16.55, and after
that, next cmd.exe starts at 13:16:59
For me it seems those "cmd.exe" starts are related to svnsync, at least
there are many of those during sync. I tried to find the error report
generated but failed. Most likely do not know how to search it correctly.
Gert
Received on 2016-01-29 12:50:21 CET