Computers are networked together and development projects of hundreds or even thousands of people are actively sustaining themselves. Without online collaboration there would be no Linux.

The magic behind collaborative project development is called version control, and as the name suggests, it's software designed to keep track of every single change or revision. This is more complicated than it sounds. What do you do if there's more than one developer working on the same piece of code? Or if an addition breaks the project in some way? RCS, the original Revision Control System was designed to address many of these problems, and in its turn the Concurrent Versions System (CVS) was designed to plug some RCS holes. Specifically, CVS was intended to handle a whole project rather than separate files.

CVS uses a simple concept. A project's source-tree is stored on the server, known as the repository. Each developer then needs to checkout their own copies of this tree by downloading the source to their local machine, which becomes their working copy. Any changes a developer makes to their working copy need to be committed back to the repository. If more than one developer has altered a piece of code, creating a conflict that CVS cannot resolve, the code needs to be manually edited before the server will allow the commit.

68_tut_svn_02.png-thumb.png (http://www.linuxformat.co.uk/images/wiki/68_tut_svn_02.png)

CVS and SVN share the same development cycle.

As you might expect, CVS is built using a client/server model. The server handles the content while the client requests changes to be made to the server's document tree.

CVS is basically a multi-document extension to RCS, and has inherited many of the problems associated with its progenitor, and even managed to add a few of its own. This is where Subversion comes in. Subversion was developed as a direct replacement for CVS, built from the ground up to solve many of CVS's problems. Top of its features list is version control for directories; not just files as with CVS. This makes a massive difference, as Subversion lets you manipulate directories in the same way you can files, moving, renaming, copying and deleting. The other big problem with CVS is also a direct result of its file based structure. It's possible to get half way through a commit and lose the connection. The result is that half the files from a developer may be updated, while the other half aren't, leaving the administrator with no way of knowing which files were updated and which weren't.

The solution, as provided by Subversion, is to make all changes to the repository 'atomic'. This means that all changes are updated as a single transaction, avoiding half updated errors and dual commits. This, along with other essential additions (resource cheap branching and tagging, excellent support for binary formats) makes upgrading to Subversion almost imperative for CVS users at some point in the not-too-distant future.

Once installed, the first step to administering a subversion repository is obviously to create the structure and populate it with files. Subversion uses the Berkeley database which restricts installation to a local file system. This is because Berkeley relies on a file system that supports relatively advanced features not currently available over a network equivalent (such as Samba or NFS). Once a suitable location for the repository has been selected, a repository can be created using a command Subversion reserved for dramatic repository changes, called svnadmin.

To create your own repository called subres, execute the following from the directory you wish the repository to reside (I've used /usr/share):

$ svnadmin create subres

Managing a Subversion repository isn't all that different from managing a CVS one but as an administrator, the most important thing to understand is the Subversion file system. This isn't a file system in the same way you think of ext3 or Reiser, but instead, it's the file structure and organisation that SVN expects. The previous command generated this structure under the subres directory, which should now contain a couple of files and several directories.

There are five directories in total; conf, dav, db, hooks and locks. Conf contains a repository's specific configuration file called svnserver.conf. The dav directory contains the system's bookkeeping information, specifically used with the Apache access modules. The aforementioned Berkeley database system uses the db directory for all its files.

Hooks are scripts that can be triggered by a specific repository event. These events include commits, or version changes, and the hook directory contains an example script for each action that SVN implements. The locks directory is used for containing the locking data, responsible for tracking accesses to the repository.