11

如果我对 mod_dav_svn 的理解有误，请纠正我，因为它基本上有两个目的：

  1. 向客户端公开 SVN 存储库（在文件系统上），客户端可以是：
    • 存储库浏览器（例如网络）
    • '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 很常用，所以我想知道我错过了什么。

4

2 回答 2

15

忘记第 2 点：HTTP 浏览。这只是一个小小的奖励。它不能取代您对Fisheye、ViewVC或（我最喜欢的）Sventon 之类的需求。

为 Subversion 服务器使用 Apache 的 http 有一些缺点：

  • 它更慢
  • 设置更难

然后，有以下优点：

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

我个人的看法：如果你是在做企业环境，使用 HTTP 或 HTTPS 协议方式的好处大于坏处。如果您谈论的是小型存储库以及您和您的朋友，我运行svnserve只是因为较低的开销和更容易的设置。但是，在那种情况下，我只是使用 Github 而不必担心。

我在我的机器上运行 Subversion 作为我的个人源代码控制系统，并在该实例中使用 svnserve。

谢谢，一些后续问题。1）当我以 svn://server/repo 访问我的 svn 服务器上的 URL 时，不也是使用端口 80 吗？2) 如果 svnserve 无法进行 LDAP 集成，那么用户可以进行身份​​验证的唯一方法是他们是否在 svnserve.conf 中的 password-db 引用的文件中（对于 svn:// 或者有一个外壳帐户）对于 svn +ssh://? 3) svn+ssh:// 不能提供 https:// 提供的相同保护，还是有区别？（对不起，我不能把每次我按回车提交的段落放在这里，我做得对吗。）-</p>

  1. 它默认使用端口 3690。这可以在您运行时更改svnserve，但是您的 svn URL 也必须反映这一点。

  2. 几乎是真的。大多数svnserve使用的地方都使用 passwd 文件。但是，从 1.5 版开始，您可以使用SASL。但是，我从未见过有人使用它。

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

于 2011-06-03T17:08:40.720 回答
2

svnserve 的简单性使其成为快速和肮脏安装的明智之选，特别是如果您在 Windows 上进行部署。

但是，当您需要记住大量密码并希望 Subversion 存储库使用与组织中使用的相同的 SSO 机制时，使用 Apache 的身份验证机制和 mod_dav_svn 会很有帮助。

在 Subversion 1.7 之前，据说 mod_dav_svn 的性能非常糟糕，并且比 svnserve 慢。据称，Subversion 1.7 提供了一个更快、更简单的 HTTP 协议，这应该使 mod_dav_svn 使用起来更可口。

于 2011-12-27T08:55:08.883 回答