Subversion Repository on Linux Dev

Question

What's the best practice for setting up a subversion repository on a linux development machine. External users need to be able to access a specific repository, but nothing else on the machine. I know one answer is to set up a dedicated repository, but I'm looking for a single machine solution: location of repositories, accounts, backup procedures.

Answer 1

One of the popular access methods to Subversion is via Apache module. You can set put different rights at the directory level to control access. See Choosing a Server Configuration and httpd, the Apache HTTP Server. For authentication, I recommend using external authentication source like Microsoft AD via mod_auth_sspi.

If you need to mix and match rights, see my answer for How can I make only some folders show up for certain developers with SVN.

Answer 2

I work for an IT operations infrastructure automation company; we do this all the time.

Location of repository: We use "/srv/svn" by default to store all SVN repositories, unless a customer has a specific requirement, for example an existing repository might be stored on a ReadyNAS shared filesystem.

Accounts: All our customers use LDAP. Either OpenLDAP server running on a master host, but sometimes Active Directory because some customers have a Windows domain in their office, which we can configure as well. Developers get access to the "SCM" group (usually svn, git or devel), and the 'deploy' group. These groups only have permissions to log in and perform SCM related activities (ie, write commits to the repo based on group ownership), or do application deployments to production.

Backup procedures: We use svnadmin hotcopy unless the customer already has something in place (usually svnadmin dump, heh).

svnadmin hotcopy /srv/svn /srv/svn_backups/$(date +%Y%m%d)

For access to the repo, it's usually simple svn+ssh. Some customers already have an Apache setup, but not many. I recommend SSH. Developers push their public ssh keys out and all is well. There's little to no maintenance with LDAP user management (the only way to go).