Just as a comparison, the same operation with the same working copy takes 2s in subversion 1.6.17 vs 1m11s in 1.7.2. This is a pretty big deal for us.
-----Original Message----- From: Peter Samuelson [mailto:pe...@p12n.org] Sent: Wednesday, December 14, 2011 4:48 PM To: RYTTING,MICHAEL (A-ColSprings,ex1); dev@subversion.apache.org Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies [Philip Martin] > That will be because commit does one or more SQLite transactions > per-node, while status has been optimised to do fewer per-directory > transactions. The number of SQLite transactions is what dominates > Subversion working copy performance on network disks. By running > commit on a subtree you are restricting the number of nodes commit has > to process and that reduces the number of SQLite transactions. This would imply that the other way to get faster commits is to specify your filenames explicitly, instead of using the default of "any changed item under the current directory". If this rather dramatic speed difference between 'status' and 'commit' is really a common case, it's probably worth reimplementing 'commit' in terms of the same thing 'status' does. But I'm not deep enough in the wcng code to know if that's a reasonable course. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
