我的老板是个好人，他愿意尝试新想法，我说服他让我在 svn 上启动新项目（而不是使用较旧的版本控制系统）。此时，我们意识到能够从异地访问我们的 svn 服务器符合我们的利益。我说这很简单，只需打开端口 80。（即使我们的 svn 在互联网上公开，我们也不需要很高的安全性，所以请不要将话题转移到 http 与 https 上，这将是一个单独的问题。显然，在我们解决眼前的问题之前，没有什么需要保护的。）
我现在发现最可怕的事情是 svn st -u 不起作用，但其他子命令可以工作，例如，svn relocate 和 svn log。具体来说，svn st -u 不打印任何输出，并挂起，直到我用 ^C 终止它。当我使用 svn 将我的工作副本重新定位到我们的公共 IP 地址时，我正确地被要求输入我的 svn 凭据，并且命令成功。svn log 打印日志，即正常运行。所有上述内容适用于在存储库根目录为公共 IP 地址的工作副本上执行的命令（或者，在 svn relocate 的特殊情况下，将存储库根目录重新定位到我们的公共 IP 地址）。对于在存储库根目录的内部网上具有服务器网络名称的工作副本，所有命令都可以继续正常工作。
为了排除外部防火墙“http 动词阻止”的可能，我尝试将访问方法更改为端口 81 上的 http 和端口 443 上的 https，每次更改服务器上的访问方法时都会重新定位工作副本。防火墙无法选择性地阻止非 http 端口的流量或动词加密的 http 动词。但这些举措并没有解决任何问题。使用 Wireshark，我能够以任何一种模式查看客户端计算机上的 svn 与我们的公共 IP 地址之间的流量，但是，我不确定在哪里可以找到对话出错的点（尤其是当协议是 https 时！）。
我们使用的是 VisualSVN Server v3.5.3“标准版”。此服务器仅支持 http:// 和 https:// 访问，不支持 svn://。客户端是 TortiseSVN v1.9.3。客户端和服务器的操作系统均为 Windows 7（它们是同一内联网上的两台不同的计算机）。
答案1
您提到您正在运行 VisualSVN v3.3.1。您使用如此旧版本的 VisualSVN 有什么原因吗？该版本现已超过一年，可能缺少与您遇到的问题相关的错误修复。我建议升级到 v3.5.3，然后查看是否仍然存在问题。VisualSVN 是一款需要非常努力保持更新的产品，特别是如果您要公开服务器，因为它使用 Apache 和 OpenSSL，由于公开披露的漏洞，它们会频繁更新。通过运行 3.3.1，您可能缺少 50 多个 CVE 补丁（请参阅https://www.visualsvn.com/server/changes/）。
如果更新版本仍然不能解决问题，我认为最好的办法是直接联系 VisualSVN 支持。
答案2
问题似乎仍然与您的防火墙或代理有关。最有可能的是，问题是由您的 ISP 设置的某些透明代理引起的。
- 您说您尝试过使用端口 443，但是当时您使用的是 HTTP 还是 HTTPS 流量？请启用真正的 HTTPS，看看是否有任何区别。
svn status -u使用 PROPFIND 请求，而 egsvn log则不这样做。那么其他类似的命令svn ls是否也使用 PROPFIND？svn log不使用 PROPFIND 的命令如何？它们有效吗？
无论如何，您都可以安装 Fiddler，捕获日志并将其发送给 VisualSVN 团队，网址为[电子邮件保护]。
安装 Fiddler，并运行命令svn status -u <URL> --config-option=servers:global:http-proxy-host=127.0.0.1 --config-option=servers:global:http-proxy-port=8888使请求通过 Fiddler。将日志发送到[电子邮件保护]我们将对此进行仔细的研究。
答案3
事实证明，使用任何代理配置我的 svn 客户端都可以解决问题。这可以在命令行上完成（如 @bahrep 的回答中所示），也可以在服务器配置文件中完成。代理可以是免费的公共代理，例如 50.97.88.2。
PS 我也联系了 visualsvn 支持，正如以下答案所建议的那样。他们就像这里一样迅速而乐于助人，并找到了相同的解决方案。