Supporting Multiple Repository Access Methods
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.
At any given time, these processes may require read and
write access to your repository:
regular system users using a Subversion client (as
themselves) to access the repository directly via
regular system users connecting to SSH-spawned private
processes (running as
themselves) which access the repository;
daemon or one launched by
—running as a particular fixed
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 Berkeley DB
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
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
program into a
wrapper script that first sets
then runs the real
client program. You
can write a similar wrapper script for the
program, and add a
command to Apache's own startup script,
apachectl. For example:
$ cat /usr/bin/svn
/usr/bin/svn-real "[email protected]"
Another common problem is often encountered on Unix-like
systems. As a repository is used, Berkeley DB occasionally
creates new log files to journal its actions. Even if the
repository is wholly owned by the
these newly created 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
db directory. This causes
all newly-created log files to have the same group owner as the
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
to have such a complex configuration.
Users who wish to access repositories that live on the same
machine are not limited to using
access URLs—they can typically contact the Apache HTTP
localhost for the server name in their
And to maintain multiple server processes for your Subversion
repositories is likely to be more of a headache than necessary.
We recommend you choose the server that best meets your needs
and stick with it!