So you want to build a software team? Part 3: Subversion

Last time we got as far as checking out the code from a local repository, and I promised we'd take a quick look at some ways of managing the repository as a network server.

There are three benefits to this:

The first that you don't have to make the whole repository writable by (and therefore susceptible to accidental damage by) all of your developers (and conversely you don't have to manage all the user and group privs and file permissions that all of them might use, which ends up locking someone out of part of the repository).

Secondly, you can give access to developers (or reviewers, managers etc) who don't have direct access to the server or need to work remotely. Even if you're using the shared drive strategy previously covered, network access also lets you use desktop SVN clients rather than ssh'ing in to the linux shell to run commands there. (Personally, I generally find the shell friendly and easier to use, but YMMV...)

Thirdly, you have the possibility of more finely-grained and easier to manage access control; you can set up groups to read and right, and even limit access to certain parts of the repository.

There are two server systems you can use: svnserve and apache (http). We'll use apache here as it works well alongside our test webserver, and has fewer problems with firewalls than svnserve.

To use apache as an svn server, you'll need to install its DAV and SVN modules. In ubuntu, this is simple: sudo apt-get install libapache2-svn (I'll assume you're on apache 2; if not, check your calendar).

Ubuntu will then create a file called /etc/apache2/mods-available/dav_svn.conf, which you'll most likely want to completely comment out and replace with a more useful configuration (but do take a read of it).

(As an aside, you may need to execute a2enmod dav_svn; I can't recall if it's enabled on install. In any case, you'll need to restart apache for it to work).

Your config, inside a standard vhosts configuration, will look much like the following:

<VirtualHost *>
DocumentRoot /var/www/html

<Location /svn/uberproject >
DAV svn
SVNPath /opt/subversion/uberproject/repository
AuthType Basic
AuthName "Uberproject Subversion Repository"
Require valid-user
AuthUserFile /etc/apache2/svn.htpasswd
satisfy all

So what's going on in there? Well, we're adding a svn path to a (possibly pre-existing) virtual host - in this case, our server. We then add a special rule for the URI to use the SVN DAV adapter to link to the repository at /opt/subversion/uberproject/repository

The rest of it (from AuthType downwards) sets up access control. Anyone who wants access will have to be listed in the /opt/subversion/uberproject/repository file.
If you want public read-only access, remove the # marks to uncomment the LimitExcept lines.

You can create and edit this file with the htpasswd command:

root@devbox:/etc/apache2# htpasswd -c svn.passwd someuser
New password:
Re-type new password:
Adding password for user someuser

Note that you only need the -c switch the first time you run the command; once the file exists you can drop it.

Note that for your respository to be usable, the repository files themselves will need to be read-writable by the user than apache runs as. On Ubuntu and Debian, that's user and group www-data. See the last installment for how that worked - if you move all your users to http access, they won't need direct write access.

You can now use the URI to refer to your repository where we used the file:// URI before.

I'm not going to cover svnserve access here; take a look at the chapter on "svnserve, a custom server" in the SVN book if you're interested.

In fact the SVN Book (aka the Red Bean book) is an excellent reference resource for SVN, so keep it bookmarked.

I'm not going to go through the full functionality here, as the SVN book will cover it all and even the built in help is very good. To use that, just type svn help at the command line. However, here are the most common commands:

svn checkout URI

Create your sandbox by checking code out from the repository. Don't try and use this in an existing sandbox! Short form: svn co

svn update

Update the current sandbox directory and all subdirectories from the repository. Short form: svn up

svn add FILENAME

Put the specified file (or directory and subdirectories) into version control. Note that this doesn't send the files to the repository; you still need to commit.

svn commit

Send all controlled changes in the current directory and subdirectories to the repository. Add -m 'Commit Message Here' to add a log message; otherwise it'll try to open an editor to take one. Short form (that no-one remembers): svn ci

This is obviously a very short list, and there are many more commands. Use the svn help or red bean for more info; we will probably touch on some (much) later in this series.

Posted by parsingphase, 2008-07-15 21:02

Anonymous user



Contact Richard