1

I'm working with an svn server that takes an extremely long time to compute merge operations. What can cause this? I've read something that indicates 1.5 is slower than other versions, is this true?

This particular server runs on centos and is version 1.5.4 (r33841)

The available resources on the machine seem ok but perhaps could be optimized. I've seen an svn server with more 4x the revisions (~2200) compute comparable merges in half the time it takes this server. What's the best setup for a linux SVN server that needs to be able to compute merges optimally?

2
  • 1
    How many revisions are there in your repository? What operating system does the server run on. What storage (BDB or FSFS) do you use? Are there any applications installed that monitor every file I/O (like antivirus software)? Does it also happen if you perform the merge locally on the server (against a file:// url?)
    – mihi
    Oct 28, 2009 at 19:24
  • What storage system do you think it should have? No antivirus software. Yes happens with server-side merges also. This repo is at r22000. I don't think the branches are very large but I suspect that could be an issue also?
    – perrierism
    Oct 29, 2009 at 15:09

4 Answers 4

1

Large Merges are painfully slow in the best of circumstances with SVN. To fix this, you switch to git. ;)

3
  • 2
    That's a solution that might work for some, but I am talking about svn. If I were starting a new development project I would consider git or mercurial but in the middle of a project switching isn't always an option. This is a question about how to optimize an svn server. Yes large merges are painfully slow with svn. I'm actually talking about any sized merge in the case of this server.
    – perrierism
    Oct 29, 2009 at 15:05
  • Merging in svn is horrible on almost every level. I would venture to say that it is pretty much a broken feature. xentek has the right answer - switch to git when you are able to. You can retain your revision history, as there is a svn->git import tool. We just made the switch about 6 months ago and it wasn't as painful as one might expect. Both our productivity and our code reliability post-merging went up. git gets out of your way. Oct 29, 2009 at 15:23
  • there is always git-svn to use git as front-end to SVN... Comment was meant to be humorous (didn't you see the emoticon?) the down vote was a bit of a jerk move, who ever you were. :p
    – xentek
    Mar 3, 2010 at 19:45
1

In Subversion 1.5, merge tracking was added, to make it easier to apply merges, and see what needs to be/can be merged. This always takes more time ofcourse, because there's more processing going on.

In Subversion 1.6 lots of changes have been made to speed up merges, and this will probably continue to be improved in newer versions. The best thing to do, is to update your client(s).

1

Are you sure it's the server? I've noticed that my merges are sometimes slow, but it's the client that's IO bound rather than the server.

0

This is perhaps a delayed response .. nevertheless .... I use SVN 1.4.3 and the merge works fine. The versions in my repositories are comparable to yours. While it is a possibility that this could be a version-related limitation (resolved by an upgrade) it might still be a good idea to look at how you are branching/merging. Is it possible to give some more details? Are you saying that the exact same merge (for eg., between the same revisions/branches) but on another server takes much less time. Incidentally how long does the merge report take exactly?

It may be nice to know how the merge is being performed just to rule out any other kind of issues before taking up upgrades.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .