Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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.
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).
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).