@madpilot makes

As a web developer, there are a number of tools in my toolbox that I find it hard to live with out. These tools for the basis of my development and deployment procedures and have not only made my life easier on many occasions, but saved my arse on more times than I care to admit.

Although these tools excel when used by a team of developers and designers, I still use then when I’m developing my own projects, such as 88 Miles. I’ve split this mini tutorial up into three parts, so that I can be a little bit more descriptive about the actual process.

Application #1: Subversion

Developing without subversion (SVN) is like throwing rocks at your house. Sure it may be fun, but sooner of later you’ll hit a window and lose all of your source code… I’ll leave the unmixing of that metaphor as an exercise for the reader. Subversion is a source code versioning system which you can think of as a safe for your source code. The concept is simple:

1. You take a copy of the source code (checkout) and you work on it.
2. When you have made your change you save the change back in to the repository(commit)
3. When you delete or stuff something up, you check the previous version out of the repository and no one is any the wiser.

SVN uses a copy-merge system which allows many people to check code out and work on it at the same time. This is handy if you have a lot of developers. Many other version control systems use the exclusive-lock in model, where a developer checkouts the file, which locks it until they are finished, which is fine too – both have their pros and cons.

Copy-merge pros:

• You can have many developers working on the same code at the same time
• If a developer leaves a project, goes on holiday falls in to a mighty cravass, there is no risk that they will have an exclusive lock on a file, stopping other developers working on it.

Copy-merge cons:

• This can get messy if two developers work on the same file at the same time. At check in time, they will need to merge their changes, and if they have been making major changes, this might not be trivial. Solving the issue requires some heavy communication (not really a bad thing) and some planning (again, not a bad thing). On small projects, the likely hood of this is pretty small

Exclusive-lock pros:

• It is impossible for two developers to work on the same file at the same time, eliminating a situation where one developer destroys another developers work

Exclusive-lock cons:

• It is impossible for two developers to work on the same file at the same time :)
• See Copy-merge pros

One of the greatest things about SVN is it’s price tag – nothing! (Don’t let that freak you out though, there are many big projects that use it – Ruby on Rails is one that comes to mind) and there are clients and servers for Windows, Mac and *nix.

Although setting up SVN itself is probably beyond the scope of this article, I’ll out line the basic procedure to set up a repository, and to work with that repository.

Setup

There is a command line utility bundled with the package called svnadmin. This, funnily enough, is the administration tool for subversion. To create a repository, you do the following:

svnadmin create /path/to/repository

Where /path/to/repository is the location of the repository. So, say you want to create project called foo in the directory /home/subversion, you would execute

svnadmin create /home/subversion/foo

And it is setup! You will probably have to play with the permissions by editing the /home/subversion/foo/conf/svnserve.conf file, for the sake of this excercise, we will allow unlimited access to the world. Obviously, in real life, you would lock it down so only those that you wanted to be able to access the code could. Check out the subversion manual for details on how to do this.

Open the svnserve.conf file and find the line that says:

# anon-access = read

Change it to

anon-access = write

SECOND WARNING: THIS IS INSECURE. DON’T DO THIS FOR A SERIOUS PROJECT. And if you do, don’t come looking for me when some one steals your code.

Now you can checkout the empty repository in to your working directory – so called because it is the directory that you work in. The command will probably look something like this (depending on our server setup of course)

Right! now you are read to start coding! Once you have finished, you can add any new files, delete any old file and then commit the changes. Just so I know what is going on, I will first check the status of the directory

A new_file_2

U modified_file

D deleted_file

The letter before the filename gives you a hint as to what you need to do – A is add, D is delete, U is modified. To complete this commit, I would run the following commands:

/path/to/working/directory% svn delete deleted_file

/path/to/working/directory% svn commit -m “Created some files, deleted a file, modified a file”

And if all goes well, subversion will return the new revision number. Revision numbers in SVN are global, so every time you run the commit call, the number will be incremented. The -m flag stands for message, if you don’t put it in, a text editor will pop up asking you to add a message. The message you enter needs to be descriptive of what you do, so that others (or yourself) can go back and see why each commit was done.

Want to rollback the changes from a commit? Say you made a BIG mistake in revision number 5 and you need to go back to revision number 4, running the following command should do the trick:

_/path/to/working/directory% svn merge -r 5:4 svn://svn.myserver.com/foo

/path/to/working/directory% svn commit -m “Undoing BIG mistake”

So revision 6 will now be the same as revision 4. Notice though that revision 5 still exists, so if you later realise that the mistake wasn’t that big after all, you can revert back to revision 5!

This is just touching the tip of what subversion can do – you can do all sorts of other funky stuff, but I’ll leave that up to you to read up on. 99% of the time, this is what a subversion session looks like for me.

Next: Trac bug tracking