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

Dragonet

You are storing a SVN working copy on a network drive? Uhh... – Stiegler

@Mike Miller No. It stores like a local copy on the DEV server. But sometimes I need to call "Commit" or simply "Check modification" from second DEV-2 server on network folder. Working copy is configured to the web server, but not to the network share. – Dragonet

You should probably report this as a performance regression to the developer of this tool. – Azotobacter

Yes, I posted this question there. Link in the update of this post. – Dragonet

So the answer is yes, you are calling commit on a working copy that is on a network share from your DEV-2 server. I am sure the TSVN guys are going to say what I am saying. "You're doing it wrong." Use some kind of remote-shell capability to call svn commit on the DEV-1 machine itself. – Stiegler

@Mike Miller note: this is not a main process for deploying. It is just a useful feature to check modifications when I logged into DEV-2. Now I should additionally login to DEV (if active sessions are exists). This worked very well in early versions. That's why I ask this question. I also found the proposals to setup some SSH tools. It should work but this is also additional step from what we have had before – Dragonet

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

Denyse

I tried it as the very first thing when I updated TSVN. Unfortunately nothing changed. Looks like this may be not fixed because it is not a common way to use new TSVN – Dragonet

This solved my problem. It seems that some overlay options and ignoring directories are crucial for big binary files to work properly. Thanks. – Manzano

Your solution works perfectly, voted and thanks, your answer should be accepted soon. – Legra

FWIW, I built a new fast Windows11 machine, installed the latest TortoiseSVN (1.14), created new repositories, started a Windows service, all on the C: drive, and the check-in dialog said "207 bytes transferred in 7 seconds" for a small VStudio project of 5 files and a few hundred lines of code using the svn://localhost/xxx syntax and the recurse into unversioned folders flag disabled as described above. – Nahuatl

Answer 2

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.

Possessive

Answer 3

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

Tertius

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.

Positivism