In my last post I promised I'd write another about subversion and how to set things up to work with contractors. I was supposed to post this the next day, but I got caught up with other things. Anyway, let's just jump right in... We run all our projects out of one big subversion repository, some people create a repository per project or group projects into a number repositories. In all honesty it really doesn't matter how you group things, I think that one repository works better for us, I can move things around and I can allow people access to all or parts of the repository. You may feel differently, but for the time being I'm going to assume you're working with a single repository like us.

getting started: installing apache, subversion and mod_dav_svn

I recently upgraded to Subversion 1.5, there wasn't a package available for the version of Fedora we're running on our server so I had to build it. It was a relatively painless process of simply making sure dependencies existed and following the instructions in the INSTALL file. http://subversion.tigris.org/getting.html Go do that now, get subversion and mod_dav_svn installed. There are more than enough resources out there on how to install subversion that I'm not going to go into too much detail about building from source or installing on any specific platform. In fact since the steps and concepts I'm going over in this post don't require a specific version I'll just throw up some common defaults. If you're on a Red Hat based linux system try: # yum install subversion # yum install mod_dav_svn If you're on a Debian based system try: # apt-get install subversion # apt-get install libapache2-svn In your apache configuration file, near the module declarations make sure you have the following lines. LoadModule dav_module /usr/lib/apache2/modules/mod_dav.so LoadModule dav_svn_module /usr/lib/apache2/modules/mod_dav_svn.so

setting up a repository

Again moving quite quickly here, there are tons of other better resources for getting started with Subversion on the web, better than I could hope to write. The basic command you need to run simply creates the directory structure that subversion needs. $ svnadmin create /path/to/repo It's usually best to create this somewhere near, but not in the document tree for the webserver. Open you're apache config file, or the config file that stores the details for the virtual host you're using and add the following lines: DAV svn SVNPath /path/to/your/repository AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/your/passwdfile Now create the htpasswd file and add a user or two using the following commands # htpasswd -cm # htpasswd -cm /etc/svn-passwd andrew New password: Re-type new password: Adding password for user andrew # htpasswd /etc/svn-passwd -m simon New password: Re-type new password: Adding password for user simon Restart apache and that's it all done. You should now have a running subversion repository with two users, andrew and simon, they should be able to view and commit anywhere. We'll assume these are staff members who can view and commit on any project.

Setting up for an external contractor

Now you want to bring a contractor in on a project, so let's create them a user: # htpasswd /etc/svn-passwd -m john New password: Re-type new password: Adding password for user john The next thing you need to do is to setup svnauthz to control access to the repository. Back in your apache config file, add the following line into your svn config: AuthzSVNAccessFile /home/goroam/dev.goroam.net/user/repos/svn-authz So that it looks something like this: DAV svn SVNPath /path/to/your/repository AuthType Basic AuthName "Subversion repository" AuthUserFile /path/to/your/passwdfile AuthzSVNAccessFile /path/to/your/repository/svn-authz I tend to keep my svn-authz file within my repository path, you may wish to place it elsewhere - whatever works best for you. The next step is to create the svn-authz file. That's as simple as this: [groups] staff = andrew, simon contractors = john [/] @staff = rw * = r [/external-project] @contractors = rw The file is pretty simple and self explanatory but the first block starting with [groups] defines the groups. In this case we've got two one for staff with andrew and simon and one for contractors with john as the single member. The usernames to use here are the same as you set in your htpasswd file. Authentication is controlled by the standard basic authentication, subversion is only controlling access. The next two blocks are paths within the repository. The first: [/] @staff = rw * = r Tells subversion to give all members of the staff group read and write access to everything under the / path - basically the whole repository. The next line * = r tells subversion to give everyone else, read access to everything. Again this may not work for you, but we tend to allow read access to everything to everyone with a password. If we trust them enough to give them a password, we trust them. Also it allows contractors to build dependant libraries from the head, which is required at times and saves us the trouble of working out dependencies in our svn-authz file. [/external-project] @contractors = rw In the next block, above, we're giving everyone in the contractors group read and write access to everything in the /external-project path of our repository. This of course is the project they're currently working, so your path will be different. That's it. Contractors hired, up and running in your subversion in minutes.

Slightly more complicated, but easy now that you know how

Let's just complicate things a little bit by adding two external contractors from the first company and a third from second working on two different projects. Let's say that CompanyA Limited are working on project-x. They've asked us to create accounts for Dick and Jane. Then we hire Dave from CompanyB to add a feature called zing-bang to project-y. You could, of course just create two accounts, one for each company - but we tend to avoid that. We like to know WHO committed what code. Not just where they were from, we work closely with our contractors and it helps us when we're communicating with them. We know how to create the users, but just to recap here we go again: # htpasswd /etc/svn-passwd -m dick New password: Re-type new password: Adding password for user dick # htpasswd /etc/svn-passwd -m jane New password: Re-type new password: Adding password for user jane # htpasswd /etc/svn-passwd -m dave New password: Re-type new password: Adding password for user dave Assuming, as above we have andrew and simon as staff users we should make our svn-authz file look something like this: [groups] staff = andrew, simon companya = dick, jane companyb = dave [/] @staff = rw * = r [/project-x] @companya = rw [/project-y/branches/zing-bang-feature] @companyb = rw We're only building slighty on the previous file with the groups entries, and that should be clear. The entry here for project-x should also look familiar - Both dick and jane, members of the companya group have read and write access to the path. For the next entry we've created a branch and we have company b working on the branch. I'm really just throwing that out there, mostly because I can, but also to show that you can go to any depth in the repository tree granting access as you see fit. In this case it's been determined that the work CompanyB in engaged to complete only needs to take place in this branch, so while they can read the whole repository they cannot write anywhere except here. This would allow you to continue internal development, or indeed external with some more entries on project-y making point releases while zing-bang feature is developed and CompanyB could merge the trunk in at will, since they have read access to it.

a lot of words

It was a lot of words, but the concepts are pretty simple. It doesn't take long to set subversion up and even with basic auth and htpasswd files it's not complicated to administer. So go on, get your contractors under control. I promise the dividends paid through increased accountability, visibility and communication will more than offset the time spent administrating the system.
Related articles by Zemanta
[[posterous-content:rrqflqEwtswDDBHalxvy]]