Does Subversion 1.5 performance hurt?

Question

We are working on a project in which everyone works from the trunk. The project has reached the point where our development team is growing, and we finally started making client releases (all good things). So, to help coordinate all of this, we started following the best practices of SVN forking / merging, etc.

The problem we are facing is that merges take more than 20 minutes and very often fail with "reset by peer" or "PROPFIND" connection errors. Branching and merging are just such a pain that they are very close to unsuitability. We only have about 1,000 files or so, and very often we merge less than 20 files, and it takes 20 minutes. We use Apache to access SVN.

My question is: is this typical or is something wrong with us? How big are your SVN repositories and how long do the merges take?

Change Access to the server is via the Internet, we have quite large binary files, we use Mac, Linux and Windows clients. There are no network or network issues that we know of.

Answer 1

This is due to Apache, see the question "Stack overflow" Svnserve VS mod_dav_svn ".

Repeat:

It seems less well known that the choice of server option used — the mod_dav_svn Apache Subversion module or the standalone svnserve server — has a big impact on the measured and perceived performance of subversion. Typically, svnserve is significantly faster than Apache mod_dav_svn ............... The most significant performance degradation was measured during the svn log and svn merge operations with the mod_dav_svn server - you will immediately notice svn log performance degradation if , eg. using the Subclipse subquery of the Eclipse subquery.

Answer 2

Full disclosure: I work with Larf, and I will tell him not to mark my answer as if it doesn’t look like we somehow installed it in the game. I would certainly love your upvotes :)

We recently tried something at work that could speed things up, and I wanted to capture it in Stack Overflow. I'm not sure if this will work for you, but it looks like it works for us.

Background

• Our repository was originally a 1.4 server.
• It has been reset and rebooted to server 1.5
• During dump and loading, the main repository of the form / svn / Projects / Project [A | B | C] has been moved to many small repositories / svn / projectA, / svn / projectB

Other symptoms

• 'svn merge' likes to accept random files and change properties. We had a folder of test scripts (about 100 of them), and for some reason, from 3-5 of them properties were randomly changed (prop was svn: mergeinfo).
• Apache logs displayed requests and history requests for / svn / Projects / ProjectA during merge, despite the fact that the structure and change of the file name occurred a long time ago.
• Looking at svn: mergeinfo in some projects showed some things related to bizarra: some files that were forever showed tag ancestors for some tags, but not all, some of them had ancestors for SVN source paths And new paths, sometimes 5+ repository paths and layouts.
• I noticed that another employee who used TortoiseSVN (I use the OSX command line) checked the “ignore ancestors” field, and its merges had the “correct” Apache logs compared to mine. His mergers also seemed to start faster.

Although they may all be completely normal, they certainly did not look as I expected.

What have we done

• I tried to move as many large, relatively static binaries as possible from the main code folders. Thus, dev branches should not clone them.
• Removed svn: mergeinfo property from EACH file. To do this, we wrote a shell script, and let it run.

Effects

Larf created the dev branch, and then a few days later tried to merge the chest into his branch. Previously, this type of merger seemed to be inhibited 13+ minutes before the merger. Now it started almost immediately and ended in <4 minutes.

We may have shot ourselves in terms of merging code with other old branches (because we removed svn: mergeinfo), but this is so rare that we were willing to risk improving the merge time of the dev branch (and all branches go forward). In addition, we are currently doing monthly releases / branches, so the following will have the correct svn: mergeinfo properties installed on them.

Answer 3

This network problem is more than the problem of subversion as such. I had this at some point, I can’t remember what I did to solve it, but a quick Google search suggests that this is not uncommon. Some things to check:

• Do you have a proxy server?
• Are you using a GUI client like Turtle? (If so, try running the command line for the same operation)

I assume you can make svn ls and simple svn co without any problems.

Answer 4

How big are your files? Binary or text? Large binary files create a large load on the server.

Also, "connection reset by peer" indicates that something is wrong on the server side. Have you checked the server load, checked the logs for errors?

Do you have problems with other network applications (browsers, access to network resources)? This indicates that something is wrong with the network itself.

I get access to a large repository (> 100,000 files) on a server on the Internet, and updates take no more than a few minutes! This is on Linux. Collecting local files is not a strong point of Windows ....

[EDIT] Your problem is large binaries. The server is probably running out of processing time or memory trying to generate xdelta. I suggest you read this article: Subversion Configuration

Answer 5

We have more than a thousand files and consistently combine a large number of modified files with conflicts. I never timed a merger, but I would be surprised if it took more than a few minutes. It may be time to pour hot water, but this is not enough to make a cup of tea!

Where is our repository located in relation to your client computer? Could you rule out any other connectivity issues?

In addition, I should probably add that we use svnserve over SSH. We always thought that we could speed things up a bit by going to Apache to access SVN, not SSH. Maybe we are wrong!

Answer 6

It might be worth taking a copy of the repository and doing a quick test with svnserve to see if it is faster. This may not be the right solution for you, but it may indicate where the bottleneck is.

From 1.5, merging requires you to get the svn: mergeinfo property for everything, which is another web call for every file for which the apache service has never been known for quick execution.

We use svnserve, svn ls -R just returned over 600,000 files in 40 projects. I never noticed that merging is especially slow.

Answer 7

We came across something similar when we stored many binaries in Subversion (many 25 MB + size). What we observed after we stopped / started the Apache service immediately showed performance, and then slowly decreased over the next week. So, we wrote a script that launched / started Apache service once a day. This greatly improved the situation.

I am not sure if this is the right solution to the problem you are facing. But maybe worth a try.

Answer 8

This is the problem that the centralized model will eventually face, and one of the motivating factors of systems such as BitKeeper, Git, Bzr, and Mercurial.