Version Control with Subversion - Login

Server ConfigurationBoth Apache and svnserve are capable of granting (or denying) permissions to users.Typically this is done over the entire repository: a user can read the repository (or not), andshe can write to the repository (or not). It's also possible, however, to define finer-grainedaccess rules. One set of users may have permission to write to a certain directory in the repository,but not others; another directory might not even be readable by all but a few specialpeople.Both servers use a common file format to describe these path-based access rules. In thecase of Apache, one needs to load the mod_authz_svn module and then add the Authz-SVNAccessFile directive (within the httpd.conf file) pointing to your own rules file.(For a full explanation, see the section called “Per-directory access control”.) If you're usingsvnserve, you need to make the authz-db variable (within svnserve.conf) point toyour rules file.Do You Really Need Path-Based Access Control?A lot of administrators setting up Subversion for the first time tend to jump into pathbasedaccess control without giving it a lot of thought. The administrator usuallyknows which teams of people are working on which projects, so it's easy to jump inand grant certain teams access to certain directories and not others. It seems like anatural thing, and it appeases the administrator's desire to maintain tight control ofthe repository.Note, though, that there are often invisible (and visible!) costs associated with thisfeature. In the visible category, the server needs to do a lot more work to ensure thatthe user has the right to read or write each specific path; in certain situations, there'svery noticeable performance loss. In the invisible category, consider the cultureyou're creating. Most of the time, while certain users shouldn't be committing changesto certain parts of the repository, that social contract doesn't need to be technologicallyenforced. Teams can sometimes spontaneously collaborate with each other;someone may want to help someone else out by committing to an area she doesn'tnormally work on. By preventing this sort of thing at the server level, you're setting upbarriers to unexpected collaboration. You're also creating a bunch of rules that needto be maintained as projects develop, new users are added, and so on. It's a bunchof extra work to maintain.Remember that this is a version control system! Even if somebody accidentally commitsa change to something she shouldn't, it's easy to undo the change. And if a usercommits to the wrong place with deliberate malice, it's a social problem anyway, andthat the problem needs to be dealt with outside Subversion.So, before you begin restricting users' access rights, ask yourself whether there's areal, honest need for this, or whether it's just something that “sounds good” to an administrator.Decide whether it's worth sacrificing some server speed, and rememberthat there's very little risk involved; it's bad to become dependent on technology as acrutch for social problems. 8As an example to ponder, consider that the Subversion project itself has always hada notion of who is allowed to commit where, but it's always been enforced socially.This is a good model of community trust, especially for open source projects. Ofcourse, sometimes there are truly legitimate needs for path-based access control;within corporations, for example, certain types of data really can be sensitive, and accessneeds to be genuinely restricted to small groups of people.Once your server knows where to find your rules file, it's time to define the rules.The syntax of the file is the same familiar one used by svnserve.conf and the runtimeconfiguration files. Lines that start with a hash (#) are ignored. In its simplest form, each8 A common theme in this book!186