为什么选择mod_dav_svn而不是svnserve和存储库浏览器?

use*_*159 11 svn apache trac mod-dav-svn

如果我对mod_dav_svn的理解错了,请纠正我,因为它基本上有两个目的:

  1. 将SVN存储库(在文件系统上)公开给客户端,客户端可以是:
    • 存储库浏览器(例如web)
    • 'svn'命令本身,它是一个客户端命令行程序
  2. 充当存储库浏览器,以便以方便的方式查看存储库

现在对于第1点,我的以下假设是否正确?

  • 无论何时使用mod_dav_svn公开存储库,都使用访问存储库的http://https://形式
  • 如果使用svnserve,则使用访问存储库的svn://形式
    • 在这种情况下,mod_dav_svn将不再使用

对于第2点,如果使用Trac的存储库浏览功能,则mod_dav_svn提供的存储库浏览功能没有其他用途?

mod_dav_svn是否有任何其他目的,我在这里没有概述?问另一种方式,使用svnserve和Trac有什么不利之处吗?

我问,因为我得到的印象是mod_dav_svn非常常用,所以我想知道我错过了什么.

Dav*_* W. 15

忘记点#2:HTTP浏览.这只是一个小小的奖励.它不会取代你对Fisheye,ViewVC或(我最喜欢的)Sventon这样的东西的需求.

将Apache的http用于Subversion服务器有一些缺点:

  • 它慢了
  • 设置起来比较困难

然后,有一些优点:

  • 它使用标准端口(80),通常不会被防火墙阻止.
  • 它可以与LDAP和Active Directory集成
  • 您可以使用HTTPS来加密更新和签出(包括用户密码).
  • 您可以让多个存储库使用相同的Apache httpd实例.使用时svnserve,每个实例只能执行一个存储库,如果在一个系统上有多个存储库,则必须svnserve在非标准端口上运行每个进程.

我个人认为:如果您正在进行企业环境,那么使用HTTP或HTTPS协议方式的优势将超过缺点.如果你正在谈论一个小型存储库以及你和你的朋友,我svnserve只是因为更低的开销和更容易的设置而运行.但是,在这种情况下,我只是使用Github而不用担心它.

我在我的机器上运行Subversion作为我的个人源控制系统,我在那个实例中使用了svnserve.


谢谢,一些跟进问题.1)当我在svn服务器上访问svn:// server/repo的URL时,是不是也使用端口80?2)如果无法对svnserve进行LDAP集成,那么用户可以进行身份​​验证的唯一方法是,如果它们位于svnserve.conf中的password-db所引用的svn://文件中,或者是svn的shell帐户+ SSH://?3)https://提供的保护不能由svn + ssh://提供,还是有区别?(对不起,我不能在这里提交段落,每当我点击输入时我都会提交.我 -

  1. 它默认使用端口3690.这可以在你运行时改变svnserve,但是你的svn URL也必须反映出来.

  2. 非常真实.大多数svnserve使用passwd文件的地方.但是,从1.5版开始,您可以使用SASL.但是,我从未见过有人使用它.

  3. 是的,ssh + svn://确实提供加密数据包.但是,SSH实现起来可能很棘手.基本上,必须为该特定用户生成并运行svnserve进程.这意味着每个用户都需要对存储库的直接读/写访问权限.您需要为每个用户设置umask并创建每个人都属于的Subversion Unix组.然后,由于这些用户可以直接访问存储库文件,因此请不要登录存储库服务器.该在线手册具有完整的详细信息.但是,最终,它只适用于Unix服务器和Unix客户端.Windows客户端上没有SSH,必须安装它.我已经尝试了几次,但https://要容易得多.