We run a number of servers behind the scenes; Version Control (SVN), Trac, ColdFusion (dev and staging), Database (SQL Server, MySQL, PostgreSQL) ...

We've now deployed a proxy server in front of it all. In this case we've deployed Squid to act as a reverse proxy.

So, basically everything now goes through the Squid server, and it routes our requests based on the domain name requested.

It was all fairly straight forward to set up, except we encounted a slight problem when it came to committing changes back into SVN.

For the life of me I couldn't figure out what was going on. As well as the introduction of Squid, we had also upgraded SVN and Trac and I assumed it was the SVN upgrade that was causing the issue.

As it turns out, it was Squid. You have to make a slight change when you're using a proxy with SVN.

As they say, Read the F*%king Manual!!! http://subversion.tigris.org/faq.html#proxy

One of the really nice things about the SVN/Trac combo is that when you commit changes to SVN, you can have the changeset update the status of a Trac ticket.

So, say the changes you have been working on, have tested, and are now committing back to SVN fix a specific ticket within Trac, and once you've made your commit, you would then log into Trac and close the ticket there.

You could also do this via the superb Mylyn integration if you're using Eclipse - which you should be :)

Well, how about updating the actual status when you do your commit? One action to rule them all, so to speak.

Well, this is possible, and here's how to do it.

The main reason for posting this, is that I've recently upgraded our Trac environment from 0.10 to 0.11 and I noticed the trac-post-commit was now broken.

The following is for Linux, so you'll need to Google for Windows.

Grab the trac-post-commit script

You need to pull the latest working version of the script from the Trac SVN repository.

Next rename the file you've just exported by sticking a ".py" on the end - it's a Python script.

Next make sure your post-commit script file is named appropriately (post-commit funnily enough) and make sure that execute permissions are set on the file. You know, chmod ugo+x post-commit

Edit the post-commit script

Next, edit your post-commit file and add the following line - this is the reason ours was broken.

Now add the following line, and this is the one that calls the trac-post-commit script

Just to be on the safe side of everything, just Apache a restart.

Commit Your Change

Now, from within Eclipse, when you want to commit your changes, you can now put the following in your comments (and you are filling in comments aren't you?????!!!???"

The following commands are supported:

• close
• closed
• closes
• fix
• fixed
• fixes

The above will close the specified ticket number, in addition to adding the message you have specified.

Also, you can use the following commands:

• references
• refs
• addresses
• re
• see

The ticket numbers specific here are left as is, but the contents of the commit messages are added to their notes.

A quick example would be something like:

This commit message will close tickets 100 and 102, and add the commit message to ticket 85.

At the risk of doing my company (Fuzzy Orange) out of business, I thought I would blog about how to set up SVN and Trac on Windows.

There has been a lot of discussion on this at the ScottishCFUG Google Group, and as much as I'd love to just say "Use Linux, it's easier", some folks aren't in that position.

So here it is:

Installing and Configuring SVN and Trac on Windows

Please leave comments, suggestions, questions, problems, etc here and I'll do my best to answer you.

We've been having a right good old natter on the ScottishCFUG Google Group, in particular about why Version Control is essential to all software development.

One of the group members asked:

All that you mention sounds very cool but i want to see what benefits it can bring a sole developer.

A reply by Alan Williamson, in my opinion, was so important I wanted to repeat it here.

and there in is the trap that many lone consultants/developers face; stop thinking of yourself as a single entity, but as a member of a team that, at present has only one member.

Alan also followed this up by stating:

I really don't know how anyone can work without version control and still claim to develop software. Bold statement? yes, but i stick by it.

I agree 100%. Any software development company who is without Version Control is ... well, it is appauling. Not only are they putting their clients at risking by not taking their business and indeed livihood seriously, but they are also inflicting damage to themselves by not making themselves as proficient as they could be, but they are also damaging their own reputation... I look on any software development firm who doesn't use Version Control as one who shouldn't be in this business. Calling them amateur, well I think I'm being rather generous.

In the past, when I've been the client, one stipulation I've also insisted on being in any contract is that the company doing the work has a Version Control system in place. If they didn't, end of conversation.

Even as a sole developer you should be using Version Control.

So, just to finish up, here's a couple of reasons why you should be using Version Control. Feel free to add more by leaving a comment.

• Provides a history of all changes
• Recover accidental deletions
• Helps co-ordinate new releases by deploying a build corresponding to a specific revision.
• Supports development by X number of developers
• Enables remote working if your repositories are public facing (and secure).
• It's not just for code. You can store all your contracts, legal documents, staff policies in Version Control.

I'm quite heavy handed when it comes to commenting my code.

As well as inline comments, I always have a config comment at the top of every file.

In addition to basic information such as Author, Filename, when the file was created, I use Subversion to get information such as: the current revision, when was the file last updated, who updated the last file.

To automate the process, I have a CFEclipse snippet that is saved as a template (require separate ones for both CFM and CFC files). So when I create a new file, I create it from the template, and this runs the snippet automatically, prompting me to fill in certain information. You can see the snippet below.

Once I commit this file to Subversion, the Subversion properties are populated, meaning I end up with something like below.

To get Subversion to actually populate your comments you need to assign a new property to every file/folder in your application.

You can either do this by running the following command:

Or from within CFEclipse, simply right click your Project folder and choose "Team" > "Set property" and then add the new property as indicated in the image below.

With every commit, you'll now see the most up to date Subversion information directly in your comments.