在svnsync中处理大文件

Meh*_*hdi 5 svn visualsvn-server svnsync connection-timeout

我们计划在悉尼的另一个办公室拥有一个SVN镜像存储库.我们在两个位置都使用VisualSVN服务器v2.5.7.

我决定用svnsync它来做.起初我想同步所有存储库,当所有存储库与镜像存储库同步时,调度程序将svnsync每隔午夜调用一次.

它可以同步我们的一个存储库的167个修订版.但是在第168次修订版中,我们有一个无法同步的大文件(大约250 MB的压缩oracle文件).即使我修改了本地和远程服务器的超时,它也无法正常工作.它在一个点上粘了大约一个小时,并给我以下错误:

传输文件数据....................... svnsync:E175002:PUT为'/ {some path}/{ bigfile } .zip':无法发送请求body:已建立的连接已被主机中的软件中止.<{ target url }>

以下是我在httpd-custom.confVisualSVNs的Apache服务器(本地,镜像)中的文件中所做的修改:

Timeout 300000
KeepAlive On
MaxKeepAliveRequests 0
KeepAliveTimeout 300000

<IfModule dav_svn_module="">  
  # Enable a 1 Gb Subversion data cache for both fulltext and deltas.  
  SVNInMemoryCacheSize 1048576  
  SVNCacheTextDeltas On  
  SVNCacheFullTexts On
  #SVNCompressionLevel 9
</IfModule> 
Run Code Online (Sandbox Code Playgroud)

我甚至将超时时间增加到600000或更多,但结果是一样的.我以http模式启动了两台服务器.在我们的本地网络上,它可以在20分钟内同步所有存储库.

关于我们的互联网连接的上传速度大约是256 Kbs,我不希望这次在互联网环境中.但我希望SVN服务器等待我为它们设置的超时,因为我们可以轻松地将这些大小的文件提交到使用CollabNet Server的其他SVN服务器.成功提交只需2个小时.我认为300000秒的超时距离是2小时.

bah*_*rep 2

将您的 VisualSVN Server 实例升级到最新版本。

从 Subversion 1.8 开始,serf使用性能更好的 HTTP 客户端库,而不是旧的neon. 因此,在svnsync不稳定的低带宽连接上使用时,您可能会遇到更少的问题。

关于我们的互联网连接的上传速度约为256 Kbs

从版本系列 3.0 开始,VisualSVN Server Enterprise Edition 有一个特殊功能可以帮助您消除低带宽瓶颈:多站点存储库复制 (VDFS)

与基于直写代理的复制系统相比,基于 VisualSVN 分布式文件系统的 Subversion 存储库的复制速度快了 10 倍以上(据我所知,您现在正在使用直写代理)。

除此之外,VDFS 支持锁定、复制用户访问权限并确保 SVN 挂钩脚本在所有复制存储库上的一致执行。