(Suggested title: Using Subversion for revision control) (unfinished)


This node seeks to provide a logical and conceptual homologue of a similarly-titled node. This node is perhaps not as timely as it could have been had I posted it around the time that I started it, but several Real Life tm things have gotten in the way and I'm only now making a return to PerlMonks. However, I do hope that it has some use for people not yet familiar with SVN.

Intended audience

This node targets the following groups (though others may gain something from it as well):

What does this node cover?

This node provides all of the information for a developer to start utilising an already setup SVN system to manage their files. I will discuss at some length the following concepts and procedures:

What does this node not cover?

There are a few issues which this node cannot feasibly cover without becoming too large, and too mired in details. The most significant of these is that I cannot possibly cover all of the possible ways to install and configure SVN. In trying to keep this tutorial as platform-independent as possible, I cannot faithfully detail the myriad possibilities of SVN configurations without certainly missing a popular configuration. In addition to setup and configuration issues, this tutorial sticks to the basics. Thus, I won't be covering the SVN Perl API as I haven't yet found a way to employ it on Windows systems. I will gladly add information on using the SVN Perl API on Windows, if someone provides me with such. Another important facet of development with SVN that will be missing from this tutorial is the concept of hooks, which allow you to execute programs when certain actions occur (e.g. running a shell script when someone makes a commit).

Why use revision control?

To echo the advice given here: because you should. But, as I'm quite fond of saying, because isn't a reason, and neither is because you should. Thus, here are some real reasons to use an RCS:

Why Subversion? Doesn't "subversion" have a meaning similar to "sabotage"?

SVN offers a number of things beyond CVS. I'll leave it up to the developer to decide whether they want to use SVN. And yes, the name has a meaning similar to "sabotage". My only idea on this is that it's not so much subversion as sub version, i.e., a sub version, like version 2.5.4 of a program, where 5 is the sub version.

Enough prattling; how about actually getting some useful work done?

Creating a Repository

You create a repository with SVN using the svnadmin tool. Its syntax is available upon request with the svnadmin help command. As you can see, the programs of SVN work very similar to those of CVS: the program name is given, then a general action is specified, followed by command line options and arguments for the action.

All that's well and good. But it's not actually getting us anywhere. You need a directory name in your filesystem under which your repository will live. In these examples, we'll use /usr/home/user/repo as the top-level directory of the repository. Feel free to substitute something more appropriate for your configuration. So, let's get started (finally). To do this, we use the svnadmin create command, like so:

svnadmin create /usr/home/user/repo

Assuming you have write permission to the directory in question, the files written by the process won't cause any quota problems, and you generally don't reach any system limits, you should have a freshly-minted SVN repository at the given directory. Let's take a look, shall we?

$ ls /usr/home/user/repo README.txt conf dav db format + hooks locks $