You've seen how a repository can be accessed in many different ways. But is it possible—or safe—for your repository to be accessed by multiple methods simultaneously? The answer is yes, provided you use a bit of foresight.
在任何给定的时间，这些进程会要求读或者写访问你的版本库：
常规的系统用户使用Subversion客户端(客户端程序本身)通过file://URL直接访问版本库
常规的系统用户连接使用SSH调用的访问版本库的svnserve进程(就像它们自己运行一样)；
An svnserve process—either a daemon or one launched by inetd—running as a particular fixed user
一个Apache httpd进程，以一个固定用户运行
The most common problem administrators run into is repository ownership and
permissions. Does every process (or user) in the preceding 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.
So the next step beyond setting up a common group for repository users is to
force every repository-accessing process to use a sane umask. For users
accessing the repository directly, you can make the svn
program into a wrapper script that first runs umask
002 and then runs the real svn client
program. You can write a similar wrapper script for the
svnserve program, and add a umask
002 command to Apache's own startup script,
apachectl. For example:
$ 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.
Once you've jumped through these hoops, your repository should be accessible by all the necessary processes. It may seem a bit messy and complicated, but the problems of having multiple users sharing write access to common files are classic ones that are not often elegantly solved.
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:// URL. And
maintaining multiple server processes for your Subversion repositories is
likely to be more of a headache than necessary. We recommend that you
choose a single server that best meets your needs and stick with it!