CODEWITHSUNDEEP
svntortoisesvn
antik
antik

Reputation: 5330

Querying for svn revision suddenly seems slow (since svn 1.5 maybe?)

Shortly after upgrading our repository to Subversion 1.5, my team switched to writing a new application for a few months and then abruptly returned to our original codebase. Our developers are using TortoiseSVN 1.5.9 and Subversion Client 1.6 (only for svnversion -n) and Subversion 1.5 on our server. Our clients connect via svn+ssh.

Our original codebase integrates the SVN revision number into the code using svnversion -n to query for the WC's current revision. Suddenly however, this operation has gone to what I recall taking a short second or two to as long as 10s (and I've seen worse still inside of VM development environments, etc.) We've also experienced similar delays going back and experimenting with Tortoise's SubWCRev and Subversion Client 1.5.

This is not a massive problem but it is certainly an annoyance as this check is made as a pre-compile step before every build operation. As such, I'd love iron those few seconds out of our feedback loop!

So, my question: Have I simply been away from my old codebase too long or has anyone else noticed a delay for this operation?

If this delay is a new phenomena, has anyone fixed it. If so, how?

Upvotes: 3

Views: 4858

Answers (4)

calandoa
calandoa

Reputation: 6137

Within (correctly configured) zsh, you can try this in your svn root folder:

sed -ns "4 p" **/.svn/entries | sort | uniq

It will give the revision of your latest update, or the list of revisions if your repository is mixed. It is not as complete as what is doing "svnversion", and it may not be compliant with all svn versions (mine is 1.6.16) but it does the job in some cases and it is incredibly fast (1s vs 3mn in my case!)

Upvotes: 1

Joshua Kugler
Joshua Kugler

Reputation:

I just solved a problem like this on my server. What are you using for auth? A checkout, commit, or log operation is a series of several HTTP requests. In the case of a log display, it's hundreds. If you have an auth layer there, it will be auth'ing on every request. If you're authing against a slow back-end that will slow you down. In my case, we were authing against our IMAP server (a custom mod_auth_imap). Once I added caching to the auth layer (keep hash user/pass pairs around for sixty seconds) it drastically sped things up: checkouts used to take 1.5 minutes and now took three seconds.

Upvotes: 1

Peter Parker
Peter Parker

Reputation: 29715

I agree with John Weldon. If you are using Apache (http(s)) then there is the possibility to slow down your svn log command. This happens on commits with a lot of filepaths changed/added. One solution is to remove path based authorisation or remove the particular revision. See for a more details here:

All of this path checking can sometimes be quite expensive, especially in the case of svn log. When retrieving a list of revisions, the server looks at every changed path in each revision and checks it for readability. [...]Needless to say, this can be time-consuming on revisions that affect a large number of files. This is the cost of security: even if you haven't configured a module such as mod_authz_svn at all, the mod_dav_svn module is still asking Apache httpd to run authorization checks on every path.

Upvotes: 4

John Weldon
John Weldon

Reputation: 40749

In the highly recommended red-bean svn book they state that large commits (many files in one commit) can greatly impact performance. Did you check in a large number of files recently, say in the last 100 check ins?

Upvotes: 2

Related Questions