Introduction

My previous post talked about configuring Redmine issue tracker and project management system to link in to Subversion. This post will focus on tweaking your svn setup to make it as easy as possible to associate checkins with redmine issues.

Showing related commits in redmine relies on developers remembering to enter issue numbers in their commit messages. On Windows, we use TortoiseSVN, and it turns out this has issue tracker support built-in. If you go to a top level checked-out folder (e.g. trunk) and open TortoiseSVN > Properties, then click New > Bugtraq, you will see this dialog:

This configures a number of useful features. The first thing is the URL of your issue tracker. This means when viewing the svn log, you can click on issue numbers and it will open the issue in your web browser. Remind me to enter a bug ID means if you forget to enter an issue number, Tortoise will warn you:

Next are the message settings. What this enables is a dedicated box in your commit window for entering issue numbers:

The implementation is quite basic, because Subversion doesn’t natively support issue numbers, whatever you enter in the box is put into the commit message either at the start or end, in the format specified by Message pattern. We have it set so that you simply enter the number in the box, and it prepends it with “Redmine Issue #” which is picked up by Redmine.

The Regular expression setting allows you to enter an expression which will recognise issue numbers when entered manually in the commit message. This is useful as you can enter multiple issue numbers and include a comment about each one. We have this set to recognise simply “#1234”, to match our Redmine setting.

Once this is set up, if you Show Log you will see an extra column dedicated to showing the issue numbers:

Notice how some issues have been entered via the “Redmine Issue #” box, and others entered plain in the commit message, but all are recognised and shown in the column. In the commit message you can see that the issue number is hyperlinked to the Redmine issue page.

We also find it useful that you can search for issue numbers in the log (or merge) dialog to quickly find all revisions relating to an issue.

As a bonus you may be interested in this Tortoise plugin which allows you to pick issue(s) from a list directly from the commit dialog, and automatically populate the comment: http://code.google.com/p/redmine-projects/

Gotchas

If you set this up as per the above, there is one problem you will likely come across. This is that after a commit, the revision will not immediately show up on the issue page in Redmine. It will only show up after you have browsed to the Repository tab, which is when Redmine refreshes its repository history.

To solve this, first go back to Redmine Repository settings and enable the WS for repository management, and generate an API key:

Now, you need to set up a post-commit hook which will ping Redmine every commit, to instruct it to update its repository cache. We use VisualSVN Server, and in this you go to the repository properties, Hooks, Post-commit hook. In theory, this is as simple as adding this command to the hook:

wget http://redmine-url-here/sys/fetch_changesets?key=api-key-here -O – -o NUL

This will do the job. However, if you have an active repository we have found that during a busy period Redmine will get too many requests to this web service and it will slow down and eventually crash. To work around this, we have instead set the post-commit hook to populate a text file using this command:

echo %2 > “c:\scheduled tasks\update-redmine.txt”

This will put the latest revision number into that text file whenever a commit is made. Then we have a batch file which is set up as a scheduled task to run every minute (but not if it is already running), containing:

IF EXIST update-redmine.txt wget http://redmine-url-here/sys/fetch_changesets?key=api-key-here -O – -o NUL

IF EXIST update-redmine.txt DEL update-redmine.txt

Essentially we are using the presence of the text file to denote that commits have been made and Redmine needs to be updated. This ensures that the web service is only called a maximum of once per minute, and never concurrently.

Summary

We have been very impressed with Redmine, and getting it fully integrated with Subversion has helped make it an integral part of our development process. If you’re using Redmine then be sure to set it up with your version control system for maximum benefit!

Introduction

Here at e3 we use the open source Redmine project management and issue tracking tool. We chose it for its issue tracking features but we’ve been surprised by how many other useful features it has such as wikis, forums, gantt charts, documents, repository integration, etc. It’s also been very reliable and there’s heaps of plugins available to add more features.

We spent a lot of time integrating Redmine as tightly as possible with our source control system (Subversion) and this is what I am going to go through here. It was through various sets of documentation, and trial and error, that we have got to what we feel is a very nice link between these two systems.

Redmine setup

The first thing you need to do is to enable repositories in Redmine settings. Enable “Autofetch commits” and Redmine will update from your repository automatically when you view a repository page. The webservice and API key we will come back to later.

Once you have done this, you will be able to edit any project and configure the repository tab. Make sure you enable the Repository module first, then configure it by entering the URL to the project root. In Subversion this is usually the folder above trunk. Enter a login which has read access to the repository, Redmine will use this to fetch commits.

Note that if you make use of sub-projects, you only need to configure the repository on the top level project, and all the features below will become available in the sub projects.

Now you can click on the Repository tab and Redmine will download the history of the repository into its database. For a large repository this will take a while. We have found that in some cases Redmine will struggle to respond to normal requests while this is happening, so I recommend if adding an existing repository then you do this at the end of the working day when no-one is relying on Redmine.

There is an excellent repository browser at the top, and a list of recent revisions underneath, and of course it shows the commit message. If you click on a folder in the repository browser then the list of revisions only shows those which affect that part of the tree. You can also view diffs between any two revisions right within Redmine, either inline or side-by-side:

Now in the rest of the project you can use the syntax “r123” to link to a particular revision. So in issue descriptions, comments, wiki pages, you can use this to link to the Repository tab showing a particular revision including diff. But what would be really nice is if it automatically pulled in any commits relating to that issue. To enable this, go back to the Redmine Repository settings and look at the second set of settings:

Here you can configure Redmine to identify issue numbers within commit messages. It will always expect them formatted with a leading hash, i.e. “#1234”. Referencing keywords allows you to restrict it further so you have to lead with a word. For example, if you enter “issue” as a referencing keyword, then you will have to enter issue numbers in your commit messages in the format “issue #1234”. If you enter * then it does not require any keyword. It’s worth mentioning you can enter multiple issues into one commit if required, as long as you prefix each with #.

Fixing keywords allow you to automatically change the issue’s status or % done when the issue number is prefixed with that keyword. For example you could set it so that when you include “resolves #1234” then Redmine will change that issue’s status to resolved. We have opted not to use this because we generally like to put a comment into the issue at the same time as resolving it.

Time logging allows you to enter in the commit message the amount of time spent on the issue. We haven’t really used this, but it allows you to enter in the commit message like “#1234 @1h30” and this should be logged in the Spent Time log in Redmine.

Now for the best part. Once this is in place, you can browse to an issue, and you will see the list of Associated revisions which reference that issue (including commit messages). You can click through to the revision in the Repository tab and view the diffs.

This is very useful when an issue is passed between developers as they can see at once both the history of the issue and the work done on that issue, as well as the code changes.