4

We're having a problem with SVN... Subversion clients such as TortoiseSVN hang when we commit any more than a few files at a time to our server. Everything appears to actually be committed successfully to the repository; but the client hangs after all the data has been transmitted.

We're using version 1.4.4 of the SVN server. We use the svn:// protocol rather than http to connect.

We've reproduced this problem with several clients: TortoiseSVN (1.6.10), AnkhSVN (2.1), and the Silk command-line client (1.6.12). This is happening for everyone on the team, though some people seem to be more affected than others. If someone commits only a few files, it often works; but with more than half a dozen files, it usually hangs.

Does anyone have troubleshooting suggestions? This has been happening sporadically for a while, but it's become pretty consistent lately. We've been working around the issue by killing the hung SVN client, doing "svn cleanup", and then doing "svn up"; but sometimes that causes tree conflicts. Another workaround is to blow away the workspace and check it out again after every commit; but of course that's pretty annoying.

Are there any diagnostics that could help us troubleshoot this? We're considering upgrading to SVN 1.6 server, and installing the server on a new machine; but we're wondering if there's an easier solution.

Thanks for your help,
Richard

2
  • 2
    Upgrading to 1.6 is a good idea either way, 1.4 doesn't support the new merge API. Oct 6, 2010 at 19:27
  • Thanks Hubert. Yeah, we should upgrade to 1.6, we just haven't had time yet. It's a bit more manageable now... I've found things are worse in Ankh, and better with Tortoise and the command line. We're also committing fewer files at a time now that the project structure is stabilizing... Oct 19, 2010 at 19:18

2 Answers 2

1

You can try strace svn daemon when the problem occurs to see what's going on there.

0

Svn is very bad performing on filesystems, especially NTFS wich is the filesystem more slow accessing many little files....

Try to move your working copy on a FAT 32 / FAT 16 formatted external hard drive, or to use it from linux (ext3) but don't expect it to be too speedy (it's also svn architecture that's bad with his too many ".svn" files)

Another thing i did to avoid these problems is to select only the changed files instead of all the base working copy before a commit

Anyway i had your same problem for years... Now i discovered Git wich was developed by a Linus Torvarlds with filesystems and speed in mind, i reccomend you to give it a try also because github is awesome and learning it dicloses much power to a developer.

You must log in to answer this question.

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