Posterous theme by Cory Watilo

TortoiseSVN/Redmine integration

Spent the day working on integrating TortoiseSVN commit logs with Redmine issues.  Some cool stuff is possible.  This post is an adaptation of my status update for this task in my list, so it may not be completely coherent, but here it is:

Accomplished so far:

TortoiseSVN integration:
  1. Added bugtraq:url and bugtraq:logregex properties globally to repository folders
  2. Added webviewer:revision and webviewer:pathrevision properties globablly to repository folders
  3. Tested TortoiseSVN Redmine integration plugin

Redmine settings:

  1. Changed server repository settings so "fixed" keywords close and mark 100% done referenced issues

bugtraq folder properties

Configuration of bugtraq folder properties is described at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html and http://stackoverflow.com/questions/516542/integrate-tortoisesvn-with-redmine.
These are properties which can be supported by any subversion client which chooses to implement them.  TortoiseSVN supports them.
The bugtraq:logregex property tells the client how to recognize a reference to an issue ID within the comment of a log.  It's value is a pair of regular expressions which tell the client how to recognize a reference to an issue ID and then how to extract the ID number from that phrase.
The pair of regular expressions used in this case is:
([Cc]loses|[Ii]ssue[Ii][Dd]|[Rr]eferences|[Rr]efs|[Ff]ixes(\s[Bb]ug)?)\s?#(\d+)
\d+
This allows the use of the following phrases to refer to an issue ID:
  • References: refs,references,IssueID
  • Fixes: fixes,closes,Fixes Bug
Using any of these phrases in a commit log message will cause TortoiseSVN to recognize it as an issue ID.  Tortoise will highlight the phrase in the commit to let you know it has been recognized.  Then, after committing, when you check the commit log that message will show up with a link for the ID number.  The bugtraq:url property determines how that id is turned into a link.  In this case, it points to the redmine server.  There is also a new column in the commit log which is just for issue ID so you can easily see issue ids in the log.
A log message may reference more than one issue id.  Each reference has to use the phrasing above.
The properties are set on folders.  In our case, they are set uniformly across all folders in the repository.  New folders do not get properties such as this created by default, but as long as most folders have them, it should still work.
It should still work because Tortoise examines the current working copy folder for the properties, and if not found, keeps looking higher in the working copy tree.  As long as one of the parent folders in the checkout has the properties, it will behave correctly.  Since they are currently set on every folder, the likelihood of the properties being found is high.
However, since checkouts are usually done at the project level (just for clarity: project not project group), then the properties need to be set at least at that level.  Therefore, any new project will need to have the properties set on it.  This can be done either explicitly on the project folder when it is created (preferably recursively after subfolders have been created as well).  Or it may be set recursively at a higher level in the directory tree.  This would need to be done either right after the project creation or perhaps by a periodic process sometime later.  A database commit hook could also enforce the setting of the property at the project level, but that would need development.

webviewer folder properties

The webviewer:revision property allows the TortoiseSVN client (and other clients) to relate the log back to a web-based view of the repository.  In this case, it relates to the repository view of Redmine.
When viewing the commit log for a file or folder in Tortoise, right-clicking the context menu when this property is set provides a "view revision in webviewer" context menu entry.  Clicking this entry takes you to the revision's changeset in redmine.  This is useful to see a more Redmine-integrated view of the repository than provided by TortoiseSVN.
The webviewer properties are set on folders similarly to the bugtraq properties and follows the same rules.
There is another property that allows you to go from the TortoiseSVN commit log to the Redmine view of a particular item (file or folder) at a particular revision.  That property is the webviewer:pathrevision property.  As mentioned above, it has been set.

TortoiseSVN Redmine integration plugin

TortoiseSVN issue tracker integration plugins are discussed under the heading Getting Information from the Issue Tracker at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-bugtracker.html.
TortoiseSVN integration plugins are modules that allow TortoiseSVN to retrieve an issue list from the issue tracker itself.  This makes it easier to remember the issue id associated with the changes being checked in.
Integration plugins are TortoiseSVN-specific and must be installed on the same machine as TortoiseSVN.  This means the plugin must be installed on each developer's machine.  It also means that other clients (such as the Visual Studio AnkhSVN plugin) do not get this capability as well.  This makes it easier to use Tortoise to do checkins, but is by no means a reason to abandon other clients.
The TortoiseSVN Redmine integration plugin can be obtained from http://code.google.com/p/chrismckee-project-bay/wiki/REDMINETSVN.
The Redmine plugin adds a button to the commit dialog in the upper right-hand corner.  The button is tied to the Redmine project URL by the configuration of the plugin.  Each Redmine project you are working on must have a configuration in the plugin in order for task lists to be available.
Because the plugin is sensitive to the project location of the working copy, it only shows those issues related to the project being checked in, which greatly simplifies things.  So the extra configuration is warranted and productive.
To configure the plugin, follow the directions at http://code.google.com/p/chrismckee-project-bay/wiki/REDMINETSVN#Setup.  The working copy directory is associated with the plugin and the project Atom feed from the issues list page for the project.  This configuration is done in the TortoiseSVN settings menu.  See the URL for full directions.

Redmine repository settings

The global settings for repositories in Redmine are at /redmine/settings">http://<your redmine server name>/redmine/settings under the Repositories tab.
By default, Redmine can respond to messages in the commit logs of checkins.  It automatically creates associations from an issue to a revision changeset when the issue is references in the commit log.  This makes it easier to keep track of the actual work of a task and changes made.
It can also take the action of closing an issue as well as setting the done percentage by responding to certain keywords in the commit log.
These features are similar to the earlier discussed TortoiseSVN capabilities associated with commit log keywords, but are implemented and configured separately.  The Redmine keyword recognition is performed separately from TortoiseSVN's.
There are two settings in the settings page referenced above.
The first is Referencing Keywords, which tell Redmine to make a link both in the issue as well as from the repository view.  The link in the issue refers to the repository change revision, and the link in the repository refers to the issue.
The second is Fixing keywords, which tell Redmine to set the status of the referenced issue as well as the Done percentage.
The current configuration recognizes the same words used in the TortoiseSVN integration.  refs, references, and IssueID make references.  fixes, closes, fixes bug change the status to Closed and set the Done percentage to 100%.  The ID itself must still be referenced by a pound-sign directly in front of the number such as #25.  Note that when an issue is closed, the link from the repository view still exists but has a strikethrough to indicate the closed status.