Gert Kello <gert.ke...@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
