I am surprised at how long it takes to merge a very small change from any particular branch into trunk; 1-2 minutes to merge in a few lines of text that have changed in a single text file that is only 2k long. I would like, if possible, to make merging a hell of a lot faster but don't know where to start. I have done a quick google and the possible reasons for slow merges seem to include any and all of the following: - Large repo size (both in terms of size on disk and number of revisions). Large source tree (apparently SVN has to crawl down the tree in order to work out changes) The version of SVN server / client Very large (several MB) files (we don't have very large single files so I doubt this affect us) I guess I really want to know how to find out which of the above points are making merges so slow. Right now I am in the dark as to whether it is work on the client or work on the server that is taking the most time (well I suspect it is the client since CPU usage is not massive on the server). I did think that it might be the vast amount of mergeinfo that has accumulated over 100s of merges but I have done a test where I have deleted all the merge info from a couple of branch and then did a merge and found the same slowness. So what I would like to ask is: - * How would one go about diagnosing/profiling the SVN activity? * Based on the info below, is there something really obvious that will be causing the poor performance? Thanks Chris Here are some facts / figures about our SVN setup Our SVN repository has around 32000 revisions. Repo size on disk: 8.3GB Our development branches each have around 1400 versioned folders (19,000 versioned files) SVN Server: 1.6.6 (r40053) (hosted in Apache running on Ubunto Lucid Lynx) I am using tortoise 1.6.9 on Win7 (although other members of the team use SmartSVN and they report the same sort of speed). Edit It might be worth adding that when we branch / merge, we branch from trunk and always merge the entire branch back into trunk. So all the mergeinfo is on the trunk (and branches) folder. Conclusions In my case, it appeared to be the disk access that was the bottleneck in the merge process - when I moved my source tree from my HDD to my SSD, the same merge went from 50 +/- 5s to 7 +/- 1s. Watching the tortoise SVN process in process explorer during the merge was quite telling: whilst doing a merge on my HDD the I/O bytes was between 500kb/s and 3Mb/s for most of the duration. On the SSD the I/O bytes was up to 10-20Mb/s. [Rather confusingly, some merges on my HDD were of comparable speed (and I/O bytes were similarly high) as those on my SSD - in these cases, I assume that a lot of the files being read were already in the windows file cache]. I found the following all increased merge speed Merging from & to a folder deeper down the source hierarchy: this is not really an option for us to in "real-life" because merge tracking becomes almost impossible if not recorded at the "trunk-level" folder but does show that merging much smaller trees makes the process much faster. Reducing the size of the working set being merged to helps (provided that you use the "working set" depth merge option and not the fully recursive) - so by simply deleting the folders (from my working set under trunk) increased speed.

Reputation: 7715

What determines the speed of an SVN 1.6 merge operation

I am surprised at how long it takes to merge a very small change from any particular branch into trunk; 1-2 minutes to merge in a few lines of text that have changed in a single text file that is only 2k long.

I would like, if possible, to make merging a hell of a lot faster but don't know where to start. I have done a quick google and the possible reasons for slow merges seem to include any and all of the following: -

Large repo size (both in terms of size on disk and number of revisions).
Large source tree (apparently SVN has to crawl down the tree in order to work out changes)
The version of SVN server / client
Very large (several MB) files (we don't have very large single files so I doubt this affect us)

I guess I really want to know how to find out which of the above points are making merges so slow.

Right now I am in the dark as to whether it is work on the client or work on the server that is taking the most time (well I suspect it is the client since CPU usage is not massive on the server). I did think that it might be the vast amount of mergeinfo that has accumulated over 100s of merges but I have done a test where I have deleted all the merge info from a couple of branch and then did a merge and found the same slowness.

So what I would like to ask is: - * How would one go about diagnosing/profiling the SVN activity? * Based on the info below, is there something really obvious that will be causing the poor performance?

Thanks

Chris

Here are some facts / figures about our SVN setup

Our SVN repository has around 32000 revisions.
Repo size on disk: 8.3GB
Our development branches each have around 1400 versioned folders (19,000 versioned files)
SVN Server: 1.6.6 (r40053) (hosted in Apache running on Ubunto Lucid Lynx)
I am using tortoise 1.6.9 on Win7 (although other members of the team use SmartSVN and they report the same sort of speed).

Edit

It might be worth adding that when we branch / merge, we branch from trunk and always merge the entire branch back into trunk. So all the mergeinfo is on the trunk (and branches) folder.

Conclusions

In my case, it appeared to be the disk access that was the bottleneck in the merge process - when I moved my source tree from my HDD to my SSD, the same merge went from 50 +/- 5s to 7 +/- 1s.
Watching the tortoise SVN process in process explorer during the merge was quite telling: whilst doing a merge on my HDD the I/O bytes was between 500kb/s and 3Mb/s for most of the duration. On the SSD the I/O bytes was up to 10-20Mb/s. [Rather confusingly, some merges on my HDD were of comparable speed (and I/O bytes were similarly high) as those on my SSD - in these cases, I assume that a lot of the files being read were already in the windows file cache].

I found the following all increased merge speed

Merging from & to a folder deeper down the source hierarchy: this is not really an option for us to in "real-life" because merge tracking becomes almost impossible if not recorded at the "trunk-level" folder but does show that merging much smaller trees makes the process much faster.
Reducing the size of the working set being merged to helps (provided that you use the "working set" depth merge option and not the fully recursive) - so by simply deleting the folders (from my working set under trunk) increased speed.

Upvotes: 10

Answers (3)

Todd Freed

Reputation: 933

Another factor is the relative delta between the two branches. So for example, if you branch off of trunk and then merge trunk into the branch a month later, this will take a long time, relatively speaking. On the other hand, if you merge from trunk into your branch every day, this will be relatively fast.

Upvotes: 0

Nikola Smiljanić

Reputation: 26873

One thing I've noticed while merging is that merges that use top level directory are very fast. So that merging a feature branch back to trunk or merging a range of revision from trunk to your feature branch is fast. But merging changes from a specific file somewhere in the working copy is extremely slow. For this reason I always branch the entire trunk and then change whatever files I need to, then merge the entire thing. So if your branch was created from one trunk's subdirectory this might be why it's very slow.

Upvotes: 0

Version Control Buddy

Reputation: 1436

you can also try merge in a shorter tree to find if it returns quicker to see if the smaller tree makes a difference.

Note: There has been a lot of merge related improvements in the latest version check the below link

http://svn.apache.org/repos/asf/subversion/tags/1.6.11/CHANGES

Upgrading to latest might help.

Upvotes: 1

What determines the speed of an SVN 1.6 merge operation

Answers (3)

Related Questions