On Thu, Sep 26, 2013 at 09:59:54AM +0100, Patrick Sawyer wrote: > I believe this improvement request stems from the fact that Medtronic (the > customer) did a massive commit (to a very large change-set) setting the > properties of ~300k files. > > This has caused significant performance issues especially with svn log. > There reasoning was if they could ignore properties this would help combat > these performance issues. > > Does this make sense?
This sounds as if the performance issue was on the server side. The client requests a list of changed paths if 'svn log' is run with the --verbose option (some GUI clients do this by default). Adding an option to the client that filters out some data before displaying it won't help at all because the server will still perform work to obtain and send the changed paths list anyway. The real fix for this issue would be scalability improvements on the server. That implies finding the actual bottleneck. If they have authz enabled and the bottleneck is checking authz rules against 300k paths, then there is not much we can do about this because every path needs to be matched to enforce access rules. Some performance penalty is expected and documented in this case. See http://svnbook.red-bean.com/en/1.7/svn.serverconfig.pathbasedauthz.html ("in certain situations, there's very noticeable performance loss") They can measure the authz performance penalty buy temporarily disabling authz and running the log request without it. I know of a case where someone imported close to a million paths in revision 1, and when they run 'svn log -v' against the authz-enabled server it takes forever to gather log information for revision 1. All other revisions which changed much fewer paths are fine, and the problem is mitigated if authz is disabled. Perhaps your customers are running into another bottle neck, but I think that's unlikely. But in this case tuning server-side caching (with Subversion 1.7 and up on the server) might mitigate the issue somewhat.
