I realised that I'm not very good at this when I looked at my last commit for this theme. The message was "added a few things" a message I find myself using when I have nothing else to say, or if I've done too much work and either can't remember all of what I did or be bothered writing it all out. It's bad form though, and I'm trying to learn my way into using git properly to make it happen less. Basically I'm still trying to find the right place between a commit for a unit of work and my previous more traditional view that all commits must compile and pass tests. At the same time I'm trying to reconcile that with a Kanban board way of organising what to do. How does everyone else commit? When, how often and what 'rules' do you apply?

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

• Collaborate and Connect with Subversion

The key to any successful development team, far more than any other tool, is version control. No matter how many team members you have, if you're dozens of people spread across the globe or one lone developer in a basement you need version control.

A number of free and paid for systems exist, largely they accomplish the same ends: the ability for multiple developers to collaborate on the same code, the ability to track changes and the ability to manage changes across concurrent versions of code.

change management

This is potentially the biggest benefit of any source control system, the ability to manage changes in code. Most version control systems manage changes through a series of checkouts and commits by developers.

You check the code you want to work on our of the repository creating a local copy, make changes to the code and commit your changes to the repository again. Any developers that are working on the code can update their local copies an the changes you've made will be merged in.

This can be a massive boon, even if you're working alone. Version controls systems will also let you roll changes back, so if you've made a mistake, deleted a file or need to see how something worked before you can go back to any previous version.

concurrent versioning

Concurrent versioning is a great benefit when you've released software or are developing more than one major feature at the same time. It's the process of having two working versions of the code which can be edited independently.

In the case of a released version of software this allows you to release a patch before new features still in development are ready to be released. You can patch the bug, release an update to users and then use the version control system to merge the change into the development code so that your next release with the new features gets the fix too.

If you're working on a major feature you might also want to branch your code temporarily. This would allow you to perform some pretty significant refactoring on areas of the code which would not affect developers working on the rest of the code, when you finished the work you could then merge your code into the main development branch prior to release.

what else

For more information about version control see the excellent Visual guide to version control at betterexplained.com.

How to get started

There are a number of choices and a number of web based version control systems. Opensource subversion and git are used by a large number of people and compete on features with most commercial offerings. If you don't want to set up your own server to host a repository Google code, beanstalk and lighthouse are just a few web based services that can host version control environments for you. Google code is free, but you'll need to be developing an opensource project the other two are subscription services.

I personally use subversion and love it but with any version control system, commercial or free the most important thing is to pick and fit a system into your development environment. Don't pick one that is going to force you to change the way you work. Try a couple if you can and pick the one that works best for you.