我被迫使用位于Windows域中的visual-svn-server。问题是它与Windows客户端一起使用速度超慢。奇怪的是，使用linux客户端的同一个存储库非常快。差异是3秒对90秒。我知道有人应该修理服务器，而不是我试图修复客户端，但我没有改变这样做。
所以，为了调试这个问题我用wireshark进行了一些包捕获，看起来像windows，当做'svn up'时（在最新的存储库上）做了很多ldap-negotiation实际上再次与实际的svn-谈话服务器。这需要时间。在执行'svn up'时，Linux svn客户端没有进行任何ldap调用。问题不在我的机器上，而是在我的所有同事的Windows客户端上。
我尝试使用配置选项http-auth-types（http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html）强制svn客户端为'basic'auth，但它没有帮助。我认为这将是基本的，没有ldap，http-basic-auth。我能够确认包含该设置，因为将其设置为“摘要”表示身份验证方法不可用。但即使这需要大约60秒，所以我的猜测是它在尝试进行身份验证之前做了ldap-wacko的事情。
我使用的颠覆客户端是来自乌龟svn官方版本的1.8系列。我也尝试了slicksvn客户端，它确实有同样的问题。 svn版本显示ra_serf正在处理https请求，我的存储库是位于https://my_server_intra_dns_name/的visual-svn服务器
当用浏览器打开地址时，它的速度应该很快，所以问题不应该是dns或类似问题。
我是linux的家伙，所以我对Windows有点失落，但是有没有人有想法wtf正在这里？
----编辑---- 我在Linux主机上也有linux作为客户操作系统，并且在linux下执行svn的时间大约是3s，将其与原生windows的'svn.exe比较'花了一分钟！
答案 0 :(得分：2)
如果Windows计算机与Internet的连接有限，那么您可能会注意到通过HTTPS对远程存储库运行Subversion客户端命令时的延迟。
使用流量分析器可以注意到，当Windows尝试访问ctldl.windowsupdate.com并超时时，会发生延迟。 Windows尝试访问ctldl.windowsupdate.com以检查Certificate Trust List (i.e. Certificate Revocation List)。由于Internet连接有限，Windows可能无法访问它，从而导致这些延迟。
如果不是你的情况，那么我建议contacting VisualSVN's support team for investigation。
答案 1 :(得分：0)
在我的情况下，它是由Windows代理设置 - 你在IE中设置（我使用TortoiseSVN客户端，并且Visual SVN Server设置为使用基本身份验证）。
在我设置了IE代理设置之后（对我自动，但对你来说可能是不同的）初始延迟消失了。
即使svn服务器在本地局域网上也有帮助，如果流量超过代理，我已经使用Wireshark进行了检查。在Tortoise我禁用了代理。为什么它对我的问题有帮助 - 不知道。
我最初的延迟是11-13秒。现在几乎没有。
我没有使用ssh客户端。
使用您的浏览器转到SVN服务器的http（s）位置：IE，Fireofx，等等，如果响应很快，则很可能是svn客户端问题，或者由于某些类似的设置（类似）到您的浏览器设置）。
例如IE很慢（IE之前只设置了本地连接），Firefox（具有正确的代理设置）没问题 - 而SVN服务器是本地的（听起来像某种网络/防火墙/路由问题给我，但代理设置帮助了我。）