TortoiseSVN 1.71 and VisualSVN 2.51 will not connect after update

Question

I updated VisualSVN to v2.51 and TortoiseSVN to 1.7.1 at the same time a few days ago. Before the update, using subversion worked fine for many months. Ever since the update, I have not been able to connect to the repository.

The OS is Win7 Home Premium 64bit, Visual Studio Web Developer Express 2010 is installed, all Windows Updates have been applied automatically, and I used the apache server connection with SSL, which is the same as was working before. Also browsing the repository from VisualSVN works fine.

To demonstrate the problem in a simple way, I used a Command Prompt session to try to list the files in the repository and get the error shown below:

C:>svn ls "https://robert-pc/svn/Scedule/"  --username xxx --password yyy<br>
svn: E175002: Unable to connect to a repository at URL 'https://robert-pc/svn/Schedule'
svn: E175002: OPTIONS of 'https://robert-pc/svn': Could not resolve hostname 
`https://robert-pc/svn/': No such host is known.
(https://robert-pc)

The same error occurs if I try using TortoiseSVN from Windows Explorer. Based on the answer from a similar question in Nov, 2009, I tried the following without success:

• Specified the port number in the computer name, e.g., svn ls https://robert-pc:8443/svn/Schedule/
• Allowed SVN.exe (the one installed with VisualSVN) through the Windows firewall.

I have uninstalled and reinstalled both VisualSVN and TortoiseSVN to no available. I don't see where anyone else has had a problem using VisualSVN v2.51 and TortoiseSVN v1.7.1. I wonder if the problem is how the Windows Network is configured. The Network is a simple local network configured as a Work Network under Windows 7 Home Premium. Any help is greatly appreciated.

I can successfully ping robert-pc from a Command Prompt session. I can browse the repository successfully from IE as follows: https://robert-pc:8443/svn/
(I get a certificate warning from IE, which I continue through, and then I enter a username and password.)

Answer 1

Your problem isn't VisualSVNServer or TSVN, and it was written in pure plain English

Could not resolve hostname `https://robert-pc/svn/': No such host is known.

Could not resolve hostname means you must get in your Windows at least ping robert-pc without errors before complaint to connect

I don't know, from which source robert-pc resolved before and who broke it now, but you have to restore old settings (hosts, local DNS-server)

Answer 2

This problem cost be me so much time that I'll describe here how I finally got Subversion working again in case it might help someone. I uninstalled VisualServer and TortoiseSVN. After uninstalling, I deleted some residual configuration registry keys and files, too:

• HKEY_CURRENT_USER\Software\Tigris.org\Subversion The sub keys under Server\Global had settings related to host-name.
• HKEY_CURRENT_USER\Software\TortoiseSVN
• C:\Users\Robert\AppData\Roaming\TortoiseSVN
• C:\Users\Robert\AppData\Roaming\Subversion

I think what really helped was getting rid of the old configuration entries before installing again. After re-installing VisaulSVN and TortoiseSVN, repositories could now be used. I wish I knew exactly what the problem was, but I do not. I suspect the SVN data for the working directories was corrupted because I tried to relocate the working directories by using the TortoiseSVN Relocate command in order to define the host-name when I received the error for not being able to connect to the host (BIG MISTAKE).

The rest gives details that are likely not of interest, unless they might give you a clue about the details of recovery.

First I reinstalled VisualSVN only and configured it to have an empty root at C:\Repositories, saving the previous Repositories folder with all the data by renaming it. I used the SVN commands from a Command Session to create a single test repository and successfully added a test file to the repository to see that the basics would work. The host-name was set to http://robert-pc:81/ during the installation just in case that https: was causing me difficulty (it turned out https: was not the problem).

Then I put the real data back to C:\Repositories and successfully checked out a repository with lots of files by using svn client from Command Session. This checkout made me see that some external references to other repositories could not be checked out because the host-name was https://robert-pc for the external references. Using VisualSVN, I set the host connection to use https with port 443 and checked out again as shown below:

• From VisualSVN, select Properties > Network tab
• Server name: robert-pc (same as before)
• Server Port: 443
• Check the box Use secure connection (https://) and click Ok.
• Use command line to checkout again.
• Start a Command Session.
• Change directory to an empty directory to which the files will be copied from the respository.
• svn checkout https://robert-pc/Schedule/branches/MySql (example for my case, note that path after host name is case sensitive).
• Enter password for Windows User when prompted for realm authentication, only once.
• Accept the certificate query permamently.
• Enter username and password for user defined in VisualSVN because using SVN athentication. (BTW, I think Windows Authentication is fine too.)
• All the files were checked out successfully

Next I Installed TortoiseSVN and could use it normally. Amazingly, I could use my original working copy instead of the one I had checked out from the repository. This was nice since my working copy had changes not yet committed.

Answer 3

I do think that your problem is related to the change to Subversion 1.7 on server and client and a problem with the certificate. Because you can access your server in your browser by using the URL https://robert-pc:8443/svn/, it is (in the context or your PC) a valid URL and should be usable by Subversion client and TortoiseSVN.

Try to do the following things to find the real source of the problem:

• Open a TortoiseSVN repo-browser, and enter in the URL line the URL of above.
• Have a look at the file editable by: TortoiseSVN > Settings > Network > Subversion server file > Edit and look at the section global. There you could specify where to store the SSL certificates.
• Check your directories <username>\ApplicationData\Subversion\auth, there is some of the authentication data stored. Try to delete the data, and then access your repository (with a valid URL like in the browser).
  1. Delete the contents of directory auth (same as TortoiseSVN > Settings > Saved Data > Authentication Data > Clear).
  2. Open a command shell and enter: svn log https://robert-pc:8443/svn.
  3. There should be warning displayed (error validating server certificate) and some options what to do now.
  4. Accept there the server certificate.
• Read the documentation in the "SVN red book" how to use SSL in the client, perhaps there is some information that helps you.

Answer 4

A corrupt Winsock caused similar symptoms on my server (Windows Server 2008 R2 / VisualSVN v2.5.7).

The following command, executed at a command prompt, with a server reboot fixed it.

netsh winsock reset

Boy was this a pain. Hope this saves someone else some hair pulling :-)