Gert Kello <gert.kello_at_gmail.com> writes:
> 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.
Subversion has repository handles and only attempts to open the
rep-cache once for each repository handle, the result is cached in the
handle. Running svnsync could open multiple handles but usually reuses
a single handle. In the case of file:// the svnsync client simply
reuses the handle. In the case of svn:// and http:// the svnsync client
does the sync over one connection and the server caches the handle for
the connection.
If the rep-cache fails to open when first accessed then this failure can
be cached for the entire svnsync run with the result that the entire
svnsync run will do no deduplication. This is probably a good thing if
the problem is a corrupt file that will always fail to work. It is less
good for a transient problem cause by interference from some Windows
anti-virus/indexing.
--
Philip Martin
WANdisco
Received on 2016-01-29 13:42:40 CET