6.5 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 file:/// URLs

• Regular system users connecting to SSH-spawned private svnserve processes (running as themselves) that 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 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 other users.

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 sets 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/local/bin/svn #!/bin/sh umask 002 /usr/local/subversion/bin/svn "$@"

Another common problem is often encountered on Unix-like systems. As a repository is used, BerkeleyDB occasionally creates new logfiles to journal its actions. Even if the repository is wholly owned by the svn group, 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 the repository's db directory. This causes all newly created logfiles 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:// URLs. 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!

The svn+ssh:// Server Checklist

It can be quite tricky to get a bunch of users with existing SSH accounts to share a repository without permissions problems. If you're confused about all the things that you (as an admininstrator) need to do on a Unix-like system, here's a quick checklist that resummarizes some points discussed in this section:

• All of your SSH users need to be able to read and write to the repository. Put all the SSH users into a single group. Make the repository wholly owned by that group, and set the group permissions to read/write.

• Your users need to use a sane umask when accessing the repository. Make sure that svnserve (/usr/local/bin/svnserve, or wherever it lives in $PATH) is actually a wrapper script that sets umask 002 and executes the real svnserve binary.

• When BerkeleyDB creates new logfiles, they need to be owned by the group as well, so make sure you run chmod g+s on the repository's db directory.