TortoiseSVN 1.7 extremely slow on commit and check modifications on network share

Question

This issue is related for operations with TortoiseSVN 1.7 only and on network share only.

On the dev server I have an svn working copy where I can commit something and then update on production server.
Sometimes when all active sessions on the dev server are busy (I can't connect by RDP), I make "Commit" by network share from another dev server.
So, I open DEV-2, then open network directory: \\DEV\Project and click "Commit" or "Check modification".
At this moment dialog opens very slowly (30-40 minutes). There are no unversioned files. And no matter how many changed files (can be 0).

Note: "Update" operation works fine.
Also above issues works fine with old versions of TortoiseSVN (1.6 for example).

I saw many suggestions to not use those operation on network shares, and use them locally.
But this is not a solution of a problem.
Sometimes I need to do "commit" on network share.
And again, this works fine in early versions.

Maybe someone knows how to workaround this problem? Or maybe there exists some setting which can be disabled?

I found same question on tortoise developers forum. But also without solution: http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2892466

---

Update 1:
I added a similar question on tortoise developers forum:
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2909472

Answer 1

The original poster in a later post in the tigris.org thread that you linked to says:

"I found the solution. If i deactivate

Settings->General​->Dialogs 2->Status->"Recurse into unversioned folders"

all works like before with TortoiseSVN v1.6.x."

http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2893160

Answer 2

As a workaround we have turned of the Show Locks

Right click on a folder and select Tortoise\Settings then General\Dialog 3 then deselect Show Locks

Please have a look at http://tigris-scm.10930.n7.nabble.com/Workaround-for-slow-RepositoryBrowser-on-large-repositories-td92324.html too

Answer 3

Are you using the file:// protocol? If you are, stop it now -- especially on a network share.

You should never, ever use file:// on a Subversion repository -- especially if multiple users are using it.

This is especially true since it is so easy to get svnserver, the lightweight Subversion server process, up and running. There are even directions to get this to work as a Windows Service.

The only issue is that your site blocks port 3690 on your network. However, this should be pretty easy to remedy. If not, you could get one of the many free Apache HTTPD/Subversion packages from VisualSVN, Wandisco, and even CollabeNet that allow you to easily setup a Subversion server using HTTPD on a Windows system.

The only other possible issue is that you're using your old 1.6 Subversion working directory with TortoiseSVN 1.7. The working directory layout for Subversion 1.7 has changed, and you should really do a new clean checkout.

Answer 4

The best "workaround" to this "problem" would be, in my view, to ask your administrators to improve the infrastructure of your project. SVN is supposed to help you synchronize a local copy of some source code tree against the remote original. If you are forced to log into some -remote- "dev server" from your local computer and commit changes to a --remote-- network directory, then there are clearly some constraints that keep you from working in the most optimal (acceptable) way. I can probably understand why this is done if the client does not allow you to check out a copy of the code to your local computer, but forcing people to work through RDP is absolutely insane. Don't work for people with silly demands like that. An employer should at least facilitate for you to come and work on the "dev server" and not through RDP.

A less idealistic suggestion would be to use the svn binary from the command line, on the host where the modified files are (not through a network mount). You eliminate sources of error by working with the tools directly.