Subversion协议性能

我刚刚开始/熟悉Subversion,并想知道哪种协议提供最佳性能文件://或svn://,当通过网络访问Subversion存储库时？如果我们不使用svn://协议,我们将无法使用file://协议来解决任何无法使用的功能？我们都在同一个NT域并计划使用Windows Auth并使用NTFS/UNC安全性.

TIA!

SVN Book建议您不要将file://协议用于多个用户

选择服务器配置:

不要被所有用户直接通过file:// URL访问存储库的简单想法所诱惑.即使存储库通过网络共享随时可供所有人使用,这也是一个坏主意.它删除了用户和存储库之间的任何保护层:用户可能会意外(或故意)破坏存储库数据库,使存储库脱机以进行检查或升级变得困难,并且可能导致文件权限问题混乱(请参阅"支持多个存储库访问方法"一节.请注意,这也是我们警告不要通过svn + ssh:// URL访问存储库的原因之一 - 从安全角度来看,它实际上与通过file://访问的本地用户相同,并且它可能带来所有相同的问题如果管理员不小心

如果要使用Windows身份验证,请使用http(s)协议和apache.设置起来有点困难,但不一定更快,但允许您使用标准的apache身份验证方法进行身份验证.包括各种基于Windows的身份验证方案或kerberos.

顺便说一句.通常,协议速度不是svn速度的一个因素.Svn将信息缓存在磁盘上,因此大多数常规操作都基于本地缓存.接下来,速度因子在存储库和网络带宽中,而不在协议中.

通过svn://结账/更新比http(s)://快约4-12倍.因素取决于文件/文件夹的数量和文件大小.Apache在许多小文件上要慢得多,因为每个文件都是一个完整的http请求 - 响应周期.在Tortoise中你可以很容易地看到速度下降:

签出一个大的java项目如果你传输一个巨大的.jar,转移正在进行,在获取源java文件和创建包结构时,它将会丢失.

同样重要的是,svn checkout在客户端上比svn export慢,而且eclipse(java)比togoise/CMD要慢得多.