[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

svn blame unworkably slow

From: Johan Corveleyn <johan.corveleyn_at_uz.kuleuven.ac.be>
Date: Tue, 5 May 2009 16:22:56 +0200

Hi all,

We're preparing/analyzing/testing a migration from CVS to SVN for some time now. All went well until I started focusing on a particular set of files in our repo: two large xml files that are changed very often. I already reported problems with svn log on these files (see http://subversion.tigris.org/ds/viewMessage.do?dsMessageId=1980568&dsForumId=10650). But that's still manageable/workaroundable (e.g. --limit 100 and the like).

However, running svn blame on one of these files is taking a very long time:
- ~5 hours for file1.xml (2 Mb large, 5500 changes) (locally on server with file:// protocol, since https remotely generates an error after 50 minutes)
- ~35 minutes for file2.xml (1,5 Mb large, 2300 changes) (remotely over https)

Note: to narrow down on the issue, I tried this on a SVN repo only containing these two files (performed cvs2svn to a new repo, only migrating the directory with these files).

Obviously this is not usable (if only for the timeout/error when trying this over https). For comparison, cvs annotate for file1.xml took only 17 seconds.

Some info on the setup:
SVN server 1.5.4 on Solaris 10 (package from sunfreeware.com)
FSFS backend via NFS on netapp
SVN client SlikSVN 1.5.5 on Windows XP (when testing remotely)

After discussing with other developers, this is quite a big issue. Some developers that have to work on those files perform an "annotate" quite often, to investigate particular parts of the file (who/what/why/when it changed)

Is there anything I can do about this?

Should I raise this on the dev list to discuss possible improvements (e.g. caching line-based history info)? I have seen an open bug report discussing this (http://subversion.tigris.org/issues/show_bug.cgi?id=3074), but it doesn't seem to have a high priority or likeliness to be addressed.

Some more details of some tests:
$ time svn blame https://svnserver/svn/trunk/file1.xml
svn: REPORT of '/svn/!svn/bc/96061/trunk/file1.xml': Could not read chunk delimiter: Secure connection truncated (https://svnserver)

real 49m39.066s
user 0m0.031s
sys 0m0.140s

When running it locally on the server with file://:
$ time svn blame file:///path/to/repos/trunk/file1.xml

real 320m12.402s
user 305m40.880s
sys 11m54.947s

Any help is greatly appreciated.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-05 16:24:59 CEST

This is an archived mail posted to the Subversion Users mailing list.