Introduction to Subversion

Ever wanted to turn back time to that point where it all worked? You know, the version of your website or application before you tried to add that new feature?

Enter version control. Controlling versions is what subversion does. It does it well. Let's take a look and install it.

Version control makes website development much easier. As already outlined, it keeps versions, or 'snapshots', of your website during development. You can then revert to an older version (snapshot) if the path you are taking just isn't working.

Have your website serve a fully functioning version of your application while you happily extend it in the background. When the updated and extended version works, simply have your website serve that snapshot with no hassle for your users.

I highly recommend the Version Control with Subversion book. It's free and on-line. I can't possibly go into as much detail as the book but I'll take you through the basics.

Subversion Installation

For this article I am using Debian Etch which has version 1.4.2 available. Ubuntu LTS has version 1.3.1 and other distributions have different versions. The latest version is 1.4.4 and is available from source from the subversion website.

Let's get stuck in and install subversion.

sudo aptitude install subversion

That's it for the installation.

Create a repository

Let's create a repository. I'm going to create a folder named 'repository' in my home directory. It can, of course, be named whatever you like and be located wherever you like:

cd ~
mkdir repository

If you have a look inside the repository folder, there is nothing there. Let's create the skeleton structure subversion uses to control repositories:

svnadmin create /home/paul/repository

Take a look now:

ls repository/
conf/  dav/  db/  format  hooks/  locks/  README.txt

Don't change anything in the repository folder. We'll learn how to add files and projects shortly.

Initial Project

To import something to our subversion repository and begin our version control, that 'something' has to exist.

You can import whatever you like (there are a few exceptions, but not many). The most popular use for subversion is to manage projects, from small websites to very large, multi developer systems but I know of people who use subversion to control their 'home' directories.

Let's create a temporary folder for our project. We'll call it 'project1'

mkdir project1

Now start the project by creating a text file:

touch project1/hello.txt

Importing projects

I know the example project is not incredibly realistic, you could have created a rails skeleton or the base of your php website or whatever you wanted, the point is to have something to import to the subversion system.

The recommended layout for a subversion project includes three folders named branches, tags and trunk. I'm not going to go into branches and tags here but concentrate on the 'trunk' of your project. Then name is very apt - think of it as the backbone of your project - this is where the main folders and files are placed.

To import project1, issue the command (on one line):

svn import /home/paul/project1/ file:///home/paul/repository/project1/trunk
--message "Initial import of project1"

A couple of things to notice include the order of the command (source folder followed by destination) and the '--message'.

When you import a version of your project, always add a message describing what the import is. I can assure you that in a week, never mind a month, you will have no idea what version 127 was if you do not include a message.

Now what?

Well, now we delete the original project1 as we don't need it because we've imported it into the version control system.

So, delete the original:

rm -rf project1/

Check out a repository

The point of subversion is to control versions of a project.

To do this we need to 'check out' the initial project (this will be version 1). Once done, we can then adjust the project (add files, change files, etc) and at various points 'check in', or commit, any changes we have made. So the next 'commit' would make version 2 of the project and so on.

Assuming you are working on the same machine as your subversion repository (we'll talk about remote manipulation in later articles), create a 'work' directory and check-out version 1 of project1:

mkdir work
cd work
svn co file:///home/paul/repository/project1/trunk project1

Move into your newly checked-out project1 and have a look:

cd project1
ls

Look familiar? It's the original project1 we imported a moment ago.

Committing Changes

Let's make a small change to project1 and add a folder and file:

mkdir goodbye
touch goodbye/goodbye.txt

We need to add this change to subversion. This does not commit the change to a new version we could check out, but it simply tells subversion there is a new file (or folder, etc) that is part of the project:

svn add goodbye

The output will show that the directory and contents of 'goodbye' have been added:

A         goodbye
A         goodbye/goodbye.txt

To actually commit this momentous change to the project (thus creating version 2 of project1) issue the following:

svn commit -m "Added goodbye section in accordance with milestone 1"

The output will end with:

Committed revision 2.

If you want to delete files or folders from the repository, use the same syntax as shown above for 'add' but substitute 'delete' for add like so:

svn delete goodbye

To commit the changes:

svn commit -m "Deleted goodbye section"

So now we're on version 3 of project1.

Finally

There is a great deal more you can do with subversion and one other skill you will probably require early on is how to check-out different versions. We're on version 3 now, but let's say we also want to check out version 2.

Go through the same procedure as before by creating a directory but use the '-r' option when you check out the project:

cd ~/work
mkdir project1-older
svn co -r 2 file:///home/paul/repository/project1/trunk project1-older

This will checkout revision (version) 2 of project1 to the project1-older folder.

Although only an introduction, a fair amount has been covered here. You will get used to these basics very quickly and want more functionality within a very short time.

The next articles will concentrate on serving the repository so others can browse it and add the ability to manipulate the repository from remote locations.

PickledOnion

Digg it | del.icio.us | reddit | StumbleUpon