读者已经见到了访问仓库的多种方式, 但是否有可能同时以多种方式 (安全地) 访问仓库? 如果你有一点先见之明, 那么答案是肯定的.

在任意时刻, 下面这些进程都可能需要仓库的读写权限:

如果仓库要同时支持多种访问方式, 那么管理员最常遇到的问题通常与仓库 的所有权和权限有关. 前面列表中提到的进程 (或用户) 是否应该具有读写仓库 底层数据文件的权限? 假设你有一个类 Unix 系统, 一种比较简单直接的做法是 把所有可能使用仓库的用户都加入到名为 svn 的用户组, 而用户组 svn 对仓库拥有完整的所有权. 但这样做还不足够, 因为进程可能使用了不太友好的文件模式创建屏蔽字—该进程创建的文件 完全禁止了其他进程的访问.

因此, 为仓库用户创建了公共的用户组之后, 下一步是强制每一个访问仓库 的进程使用一个合理的文件模式创建屏蔽字. 对于直接访问仓库的用户, 你可以 把程序 svn 封装成一个脚本, 脚本首先执行 umask 002, 然后再运行真实的 svn 程序. 你也可以为 svnserve 程序写一个类似的封装脚本, 以及在 Apache 的启动脚本 apachectl 内添加一行 umask 002. 例如:

$ cat /usr/bin/svn

#!/bin/sh

umask 002
/usr/bin/svn-real "$@"

在类 Unix 系统上还会遇到另一个常见的问题: 比如说, 如果你的仓库是使用 Berkeley DB 作为后端存储, 那么它很少会去创建新的日志文件来记录自己的 操作. 即使整个仓库都被用户组 svn 所拥有, 这些新创建 的日志文件也不一定属于用户组 svn, 这会导致更多的权限 问题. 一种比较好的解决办法是为仓库的 db 子目录设置 SUID, 这将使得所有新创建的日志文件都具有和父目录相同的用户组.

一旦你克服了这些困难, 此时仓库对于所有必要的进程来说, 应该都是可访问 的了. 虽然看起来可能有点凌乱和复杂, 但是对于如何处理多个用户共享相同文件 的写权限这个问题, 一直都没有一个优雅的解决办法.

幸运的是, 大多数仓库管理员 不必 进行这么复杂 的配置. 如果用户想访问托管在本机上的仓库, 除了 file://, 其实还可以使用 http:// 或 svn://, 在填写主机名时需要写成 localhost. 为仓库支持多种访问方法可能比看上去更麻烦, 我们建议你选择一种满足自己需要的访问方式, 然后坚持用它!