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.

I blogged around a month ago stating "Version Control: You're a Fool If You Don't Use It".

Whilst the comments to that posting were pretty much all in agreement, I got some emails/IMs that weren't as enthusiastic, and thought I was being quite bold and abrasive in my claim, well....

...I'm about to make another...

If you aren't using bug tracking software you will continuously, and consistently release poor software.

The simple fact is that you need a proper way to organise all the things currently wrong with your code. It also gives you a way to record enhancements you or your customers would like to see. NO, a list of emails doesn't cut it.

Companies I have worked for in the past didn't maintain any formalised record of bugs - again, NO a list of emails doesn't cut it. Looking back, we simply were nowhere near as productive as we could have been, and yes, as far as I'm concerned, we released crap software. Fact.

The last company I worked for, before founding Fuzzy Orange, I put in place both Subversion and Trac. I put them in place before I did anything else, much to the annoyance of management. Given time though, management discovered that by doing so we ended up with a much more stable, maintainable and performant product. Don't get me wrong, they still complained about new features not being developed fast enough - what's new - but the product had regained credibility whereas before there was countless server restarts per day because the software was. Crap.

By using Trac, I had given the development team a centralised and searchable system whereby, we could all see:

• All the (reported) outstanding bugs
• Progress of each bug
• What milestones we were working to, and how many bugs/enhancements we still had to squash

For management, who had read-only access, they could see reports that told them:

• What our milestones were
• An estimation of when these milestones would be reached
• A count of just how many bugs were in the system
• How many bugs we had closed, and how many were closed in a given timescale

Again, a list of emails doesn't count. It doesn't give you the information you, or your fellow staffers need. You need a way to record bugs, prioritise them, assign them to developers, assign them to milestones, and you need a way to search them. So once again I will state, If you aren't using bug tracking software you will continuously, and consistently release poor software.

So, there is a question that needs to be asked. Why do software development teams operate without a bug tracker? And believe me, there are a lot who don't.

1) I'm a single developer, so I don't need one

This argument is given often, not just for bug tracking, but also when discussing version control. However, you're 100% wrong. Nope, no argument. You're plain wrong.

Even if you are the sole developer at a company, think of yourself as a development team that currently has a single person. This team may grow, and if you don't act now you'll just make life harder for yourself down the line. Additionally, using a bug tracker can allow you to track and prioritise your time and this will lead to you becoming more productive.

2) Don't have time to put one in place

Complete cop-out. You can have bug tracking software up and running in an hour.

3) All the bug trackers out there are way too complex

Then write your own. Create a single database table with the following fields.

• Short Description
• Date Created
• Steps to Reproduce
• What Should Happen
• What Does Happen
• Bug Owner
• Who is it Assigned to
• Is it fixed

Now just throw together a simple interface for this.

4) They cost too much

Absolute rubbish.

• Trac
• Bugzilla
• Lighthouse

5) We don't have the expertise, environment, resources to put this in place

Then use a hosted solution such as CVS Dude to do it all for you.

There is no excuse for not having bug tracking software in place.

One of the biggest complaints I hear about Trac, is the fact it's administrative interface is command line based.

There is a WebAdmin plugin for Trac, and I thought I would write a quick article about how to install and configure it.

Enjoy.

Configuring the WebAdmin plugin for Trac

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.

In my previous entry I quickly went through the process of setting up Trac. This set up basically worked with a single project.

You can of course support multiple projects via a single trac installation and that's what I'm going to show below.

The first thing I did was get rid of the following Alias, and replace it with ScriptAlias

I then commented out the following block and replaced it

I then updated the authentication block by doing ... and this allows us to share the same password file across all our projects.

Restart Apache and you're off...

http://mysite/trac/

Doing this will get you a list of projects you can choose from, or you can just do

http://mysite/trac/<projectname>

I should point out that there are other ways of running Trac, and different ways of supporting multiple projects. Also as I'm still learning all this stuff myself, I may not be getting everything "right", so feel free to shout in if you have suggestions.

I think I'll follow this up by talking about users and permissions ... though I believe I need to write the next entry for my AdminAPI series.