我被迫使用位于
Windows域中的visual-svn-server.问题是它与Windows客户端一起使用速度超慢.奇怪的是,使用linux客户端的同一个存储库非常快.差异是3秒对90秒.我知道有人应该修理服务器,而不是我试图修复客户端,但我没有改变这样做.

所以,为了调试这个问题,我用wireshark进行了一些包捕获,看起来像windows,当做’svn up'(在最新的存储库上)在实际再次与实际的svn-server讨论之前做了很多ldap-negotiation.这需要时间.在执行’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比较’花了一分钟！

最佳答案 如果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.