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

Solution 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

Solution 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.

Comments

[Anton Palyok]

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

[vmassuchetto]

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

[Viet Nguyen]

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

[Kevin]

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.