你已经看到了一个版本库可以用多种方式访问，但是可以—或者说安全的—用几种方式同时并行的访问你的版本库吗？回答是可以，倘若你有一些深谋远虑的使用。
在任何给定的时间，这些进程会要求读或者写访问你的版本库：
Regular system users using a Subversion client (as
themselves) to access the repository directly via
file:// URLs
Regular system users connecting to SSH-spawned private svnserve processes (running as themselves), which access the repository
An svnserve process—either a daemon or one launched by inetd—running as a particular fixed user
An Apache httpd process, running as a particular fixed user
The most common problem administrators run into is
repository ownership and permissions. Does every process (or
user) in the previous list have the rights to read and write the
repository's underlying data files? Assuming you have a
Unix-like operating system, a straightforward approach might be
to place every potential repository user into a
new svn group, and make the repository wholly
owned by that group. But even that's not enough, because a
process may write to the database files using an unfriendly
umask—one that prevents access by other users.
所以下一步我们不选择为每个版本库用户设置一个共同的组的方法，而是强制每个版本库访问进程使用一个健全的umask。对直接访问版本库的用户，你可以使用svn的包裹脚本来首先设置umask 002，然后运行真实的svn客户端程序，你可以为svnserve写相同的脚本，并且增加umask 002命令到Apache自己的启动脚本apachectl中。例如：
$ cat /usr/bin/svn #!/bin/sh umask 002 /usr/bin/svn-real "$@"
Another common problem is often encountered on Unix-like
systems. If your repository is backed by Berkeley DB, for
example, it occasionally creates new log files to journal its
actions. Even if the Berkeley DB repository is wholly owned by
the svn group, these newly created log files
won't necessarily be owned by that same group, which then
creates more permissions problems for your users. A good
workaround is to set the group SUID bit on the
repository's db directory. This causes all
newly created log files to have the same group owner as the
parent directory.
一旦你跳过了这些障碍，你的版本库一定是可以通过各种可能的手段访问了，这看起来有点凌乱和复杂，但是这个让多个用户分享对一个文件的写权限的问题是一个经典问题，并且经常是没有优雅的解决。
Fortunately, most repository administrators will never
need to have such a complex configuration.
Users who wish to access repositories that live on the same
machine are not limited to using file://
access URLs—they can typically contact the Apache HTTP
server or svnserve using
localhost for the server name in their
http:// or svn:// URLs.
And maintaining multiple server processes for your Subversion
repositories is likely to be more of a headache than necessary.
We recommend you choose a single server that best meets your
needs and stick with it!