颠覆协议性能 [英] Subversion protocol performance

问题描述

我刚刚开始/熟悉 Subversion 并且想知道通过网络访问 Subversion 存储库时，哪种协议提供最佳性能 file://或 svn://?如果我们不使用 svn://协议，会不会错过我们无法使用 file://协议进行修改的任何功能?我们都在同一个 NT 域上计划使用 Windows Auth 并使用 NTFS/UNC 安全性.

TIA！

解决方案

SVN Book 建议您不要为多个用户使用 file://协议

选择服务器配置::><块引用>

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

I'm just getting started/familar with Subversion and was wondering which protocol gives the best performance file:// or svn://, when accessing a Subversion repository over the network? If we don't use the svn:// protocol, will be missing out on any features that we couldn't mitgate using the file:// protocol? We're all on the same NT domain & plan on using Windows Auth and use NTFS/UNC security.

TIA!

解决方案

The SVN Book recommends that you do not use the file:// protocol for multiple users

Choosing a Server Configuration:

Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called "Supporting Multiple Repository Access Methods"). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful

这篇关于颠覆协议性能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！