So my boss is a nice guy who's open to trying new ideas, and I talked him into letting me start new projects on svn (instead of an older version control system). At this time, we've realized that it's in our interest to be able to access our svn server from offsite. I said that was easy, just open port 80. (We do not require high security for our svn even if made public on the internet, so please do not change the subject to http vs. https, that will be a separate question if ever. And obviously until we get the immediate problem solved there will be nothing to secure.)

The horrible thing I've now discovered, is that svn st -u does not work, but other subcommands do work, e.g., svn relocate and svn log. Specifically, svn st -u prints no output and hangs until I kill it with ^C. When I svn relocated my working copy to our public IP address, I was correctly challenged for my svn credentials and the command succeeded. Svn log prints the log, i.e., behaves as normal. All the foregoing applies to commands executed on a working copy whose repository root is the public IP address (or, relocating the repository root to our public IP address, in the special case of svn relocate). For working copies with the server's network name on the intranet for the repository root, all commands continue to work fine.

To rule out "http verb blocking" by an external firewall as an explanation, I tried changing the access method to http on port 81, and https on port 443, relocating the working copy each time I changed the access method on the server. A firweall can't selectively block http verbs on traffic that's not to the http port, or where the verbs are encrypted. But these moves did not solve anything. Using Wireshark, I am able to see traffic between svn on my client computer and our public IP address in any of these modes, however, I am unsure where to locate the point where the conversation goes wrong (especially when the protocol is https!).

We are using VisualSVN Server v3.5.3 "Standard Edition." This server only supports http:// and https:// access, not svn://. The client is TortiseSVN v1.9.3. The operating system is Windows 7 for both client and server (they are two different computers on the same intranet).

  • Good question. What do the logs say, both client and server? May 21, 2016 at 0:16

3 Answers 3


You mention you are running VisualSVN v3.3.1. Is there a reason you are using such an old version of VisualSVN? That version is now over a year old and could be missing the bug fix associated with the problem you are having. I'd suggest upgrading to v3.5.3 and then seeing if you still have the issue. VisualSVN is a product you need to be very diligent in keeping up-to-date especially if you are making the server publicly available as it uses Apache and OpenSSL which are being updating frequently due to publicly disclosed vulnerabilities. There are probably 50+ CVEs that you are missing patches for by running 3.3.1 (see https://www.visualsvn.com/server/changes/).

If updating the version still doesn't correct the issue, I'd say your best bet will be to contact VisualSVN support directly.

  • Is there a reason you are using such an old version of VisualSVN? Only fear of clobbering our repositories during an upgrade, but I got over that. (No clobbering occurred. They're backed up daily, anyway.) I edited the question to reflect the version change. Unfortunately, no change in behavior with the new version.
    – user355030
    May 19, 2016 at 0:49

It still looks like that the problem is related to your firewall or proxy. Most likely, the problem is caused by some transparent proxy that could be setup by your ISP.

  • You say that you've tried using port 443, but did you use HTTP or HTTPS traffic then? Please enable true HTTPS and see whether it makes any difference.
  • svn status -u makes use of PROPFIND request while e.g. svn log does not. So how about other commands like svn ls that also use PROPFIND? Howe about svn log that does not use PROPFIND? Do they work?

In any case, you can install Fiddler, capture the logs and send them to VisualSVN Team at [email protected].

Install Fiddler, and run the command svn status -u <URL> --config-option=servers:global:http-proxy-host= --config-option=servers:global:http-proxy-port=8888 to make the requests go through Fiddler. Send the log to [email protected] and we will take a close look at it.

  • To clarify, the protocol used on port 443 was HTTPS.
    – user355030
    May 19, 2016 at 0:51
  • svn ls succeeds. (I did not notice that before - learned something new!)
    – user355030
    May 19, 2016 at 1:35
  • Okay, now the very odd thing is "svn st -u" succeeds when I supply the http-proxy-host and http-proxy-port options, to use Fiddler as the proxy as suggested. I sent the log to support nevertheless :).
    – user355030
    May 19, 2016 at 1:49

Turns out, configuring my svn client with any proxy solves the problem. This can be done either on the command line (as in @bahrep's answer) or in the servers configuration file. The proxy can be a free public proxy like

P.S. I did also contact visualsvn support as suggested in the below answers. They were prompt and helpful just like here, and led to the same solution.

You must log in to answer this question.

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