On Wed, Jan 6, 2010 at 9:07 PM, Ryan Schmidt <subversion-20...@ryandesign.com> wrote: > > On Jan 6, 2010, at 12:31, Andreas Hoegger wrote: > >> Yes I do. You can imagine if 150 developers have been working for 5 years >> nobody will use 'blame'/'annotate' commands except for you feel infinitely >> bored at least with version 1.4 (it would take hours). Is there really >> nobody having the same problems? > > You're saying you're using Subversion 1.4 and "svn blame" takes hours to run? > That doesn't sound like it should be. > > I use "svn blame" probably daily in my work on the MacPorts project. It's not > slow. We use Subversion 1.6 now, but I don't remember "blame" ever being > slow; it returns in seconds. Our repository has over 62,000 revisions and is > 7.5 years old. We have over 120 registered committers, but probably only a > few dozen are particularly active at the moment. But "blame" is very helpful > to me in trying to figure out why a file says what it says. Just a couple > days ago I used "blame" to research the complete 2-year history of a > particular line of code, to try to understand why it was there (and not > because I was bored): >
Just jumping in here to support Andreas' complaint about blame being slow: yes it's definitely slow. See: http://subversion.tigris.org/issues/show_bug.cgi?id=3074 - Improve performance of svn annotate However, the slowness only hits you when you blame a large file with a lot of revisions. With "large file" meaning more than a couple hundred KB's, and "lot of revisions" meaning more than thousand or so. Apparently, this is not so common for "source" files (that you'd want to blame), so not a lot of svn users actually experience this. But in our repo we have a 2 Mb xml file with 6000 revisions on which blame is very useful. Blame on that file takes more than 4 hours so we don't do it anymore. Before SVN we were on CVS, and there it took 15 seconds. So I can certainly feel Andreas' pain :(. I can only hope that more and more users hit this problem, so that it gets some more attention and the issue will be addressed some day... Also, log is slow (though not as bad as blame): "svn log"-ing that 6000 revision file takes 4 minutes or so (back on cvs that was 5 seconds). Both problems are not network related (everything on a lan here), but they do have different causes: - blame is mainly client-side io-bound (client gets 6000 binary delta's and computes the line-based blame on the client side). - log is server-side io-bound (server crawls 6000 FSFS rev files to get those 6000 log messages). Our server is 1.5.4 on Solaris. Access by https (I tried http and svnserve, no significant difference) Back end is FSFS on a NAS (over NFS). Having the backend on a NAS over NFS might be a factor for log slowness (when we upgrade to 1.6.x, I hope that packing the repo might help here). I've experimented with putting the repo on local disk, and that about halved the log time (down to 2 minutes, woohoo :)). Also, BDB might have better performance characteristics for this (I haven't tested this, but this might be a reason why the svn dev's have not hit this themselves). Anyway, I can understand Andreas' desire to clean out old history that's no longer needed, and that's only slowing things down. But sometimes, having that entire history is very useful, so we chose not to do that. Instead, we learned to live with the current limitations for now, and we hope they will be improved someday... Regards, Johan
