我们有一个编译服务器,它运行我们的SVN服务器(目前是Visual SVN),也可以进行夜间构建。服务器上的本地检出需要几分钟。我正在寻找改进方法。
哪种协议提供最快的SVN服务器访问权限?
注意:安全性是服务器的一个问题。如果快速协议没有与HTTPS相同的安全级别,我们可能会尝试仅使用快速协议进行本地检查。
答案 0 :(得分:2)
file:///
协议。也许不是完整的结账,但在您的情况下更新将可用于您?
如果快速协议没有与HTTPS相同的安全级别
file:///
根本没有任何安全措施!
答案 1 :(得分:1)
您应该使用Jenkins进行构建。 Jenkins可以自动化构建,并且可以通过在每次提交后执行构建或在特定时间(或两者都执行)自动触发构建。例如,您可以说“每天晚上7点构建应用程序”。更好的是,你可以给一个安静的时期,所以在每个人都完成之前,构建不会开始。有点像说“每晚在晚上7点构建应用程序,但只有在没有人检查任何代码的情况下30分钟后”。
更好的是,Jenkins通常可以找出构建过程中更改了哪些文件,以及创建了哪些文件,然后还原这些文件。然后Jenkins可以进行更新而不是结帐,这会更快。
我敢打赌,主要的问题不一定是你的夜间构建需要太长时间才能结账,但是有人必须坐下来运行构建。由于Jenkins自动运行构建,然后通过电子邮件报告其状态,所以没有人真正坐在那里观看构建。
关于你问题的答案:
http://
和https://
是最慢的,因为所有签出都是通过Apache服务器进行的。但是,http://
可能是最受欢迎的协议,因为它具有灵活性。svn://
和svn+ssh://
速度更快,但不像http://
那么常见。file://
是最快的,但只能在服务器上使用,它使用文件级安全性来说明谁可以签入或签出文件。它永远不会被人群使用,因为任何具有签入和签出访问权限的用户也可以直接访问存储库目录下的文件。通常,用户不在Subversion服务器上,并且存储库目录只能由运行Subversion进程的用户拥有和写入(有时可读)。有些网站将Jenkins放在他们的Subversion服务器上,然后使用file://
协议进行检查。只需确保运行Jenkins的进程也运行Subversion服务器。
答案 2 :(得分:1)
还有一个选择:
svnsync
这应该解决问题是变化的大小明显小于结账的大小(可能是这样)。即使没有,更频繁地运行svnsync,也会将同步时间转移到后台,因此无论如何都会减少构建时间。
答案 3 :(得分:0)
在这里,我假设操作很长(几分钟),因为你有大量文件(或大内容)。
为避免代价高昂的结账(时间),您可以
svn revert
还原本地更改svn update
获取最新版本的更新无论您使用何种协议,此技术都非常类似于结帐,但速度非常快。