"C. Michael Pilato" <cmpil...@collab.net> writes: > On 02/14/2012 05:41 AM, Philip Martin wrote: >> A substantial performance improvement but at the cost of making write >> operations block read operations. This would mean things like TSVN >> would not be able to run status on a working copy while its checkout was >> running. > > Just to clarify, by "checkout" here, you mean "checkout or update", yes? I > ask because while checkout might be a relatively rare operation, we tend to > assume that updates happen all the time. Just want to properly frame the > scope of this blocking action.
Yes, I believe anything that writes to the database will exclude readers. I don't know whether the blocking starts from the point the database is opened for writing or from the first write itself. The performance improvements affect other commands: - a recursive commit command goes from 38s to 1.5s - a recursive status command goes from 3.3s to 1.5s. The status command appears to be influenced by some sort of NFS cache in my setup and immediately repeating the command gives a shorter runtime, in this case the time drops from 2.3s to 0.5s. The commit harvester appears to be particularly transaction intensive. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
