Version Control with Subversion - Login

Server Configuration• An Apache httpd process, running as a particular fixed userThe 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 writethe repository's underlying data files? Assuming you have a Unix-like operating system, astraightforward approach might be to place every potential repository user into a new svngroup, 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 thatprevents access by other users.So the next step beyond setting up a common group for repository users is to force everyrepository-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 andthen runs the real svn client program. You can write a similar wrapper script for the svnserveprogram, and add a umask 002 command to Apache's own startup script,apachectl. For example:$ cat /usr/bin/svn#!/bin/shumask 002/usr/bin/svn-real "$@"Another common problem is often encountered on Unix-like systems. If your repository isbacked 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 newlycreated log files won't necessarily be owned by that same group, which then creates morepermissions problems for your users. A good workaround is to set the group SUID bit onthe repository's db directory. This causes all newly created log files to have the samegroup owner as the parent directory.Once you've jumped through these hoops, your repository should be accessible by all thenecessary processes. It may seem a bit messy and complicated, but the problems of havingmultiple users sharing write access to common files are classic ones that are not oftenelegantly 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 limitedto using file:// access URLs—they can typically contact the Apache HTTP serveror svnserve using localhost for the server name in their http:// or svn:// URL. Andmaintaining multiple server processes for your Subversion repositories is likely to be moreof a headache than necessary. We recommend that you choose a single server that bestmeets your needs and stick with it!The svn+ssh:// Server ChecklistIt can be quite tricky to get a bunch of users with existing SSH accounts to share arepository without permissions problems. If you're confused about all the things thatyou (as an administrator) need to do on a Unix-like system, here's a quick checklistthat resummarizes some of the topics discussed in this section:• All of your SSH users need to be able to read and write to the repository, so put allthe SSH users into a single group.• Make the repository wholly owned by that group.190