Mission

Subissue aims to remove the database from traditional issue tracking software, using Subversion as its base. That is, rather than storing issues in a relational database, issues are stored directly in your Subversion repository, next to your source — right where they belong!

Motivation

Traditional issue tracking software can be a pain to administer. Anyone who has used Bugzilla knows what I'm talking about. There are seemingly thousands of configuration options, and such systems require a MySQL or Postgresql server as the backend. For anyone running in a hosted environment, setting up additional database services can be expensive and difficult. Even if you have your own server, additional security considerations can be a showstopper.

If you are reading this, you probably have your projects' source already stored in a Subversion repository. This means you probably have an Apache server providing remote access to your repository. Why should anything else be required? Integration with Subversion's logging features makes for a logical and complete solution. Subversion already has its own database and provides intelligent reporting, history, and access control straight out of the box: most everything required for issue tracking is already in place — right down to email notification.

General Development Overview:

Subissue revolves around three major parts: the storage specification, the web-based interface, and a pre-commit script for direct Subversion integration.

Storage Specification

Although access and editing of issues would generally be done via the web-based interface, the issues are stored in a way that makes it easy to edit and create them as you would any other file in your Subversion repository. If you plan to manually edit your issues, please read:

• the specifications for Issue Storage, Access, and Representation and Description and Comment Headers,
• and also the recommendation for Directory Layout.

The web-based interface only knows how to interpret issues that follow the above specifications, in concert with the Subissue Configuration. It is designed to make every attempt to fail gracefully should the above specifications not be followed, but no guarantees can be made. Files and directories that don't have the subissue:type property set to a valid value are always ignored. Also, issue directories that are not found in one of the Path Search List will also be ignored.

Web-Based Interface

Since Subversion servers are usually accessed via an Apache server (using the mod_dav and mod_dav_svn modules), it follows that the main Subissue interface should run on that same Apache server. The web-based interface is a work in progress, and is in the initial planning stages. It is expected that it will be written either as a PHP page or Python CGI script (not Perl, since I don't know Perl), using Subversion's client library and SWIG bindings.

Once the initial planning has been completed (and once I figure out how to use SWIG and teach myself Python :->), you can find out how to install and configure your interface by reading the Subissue Configuration page and the Web-Based Interface page.

Pre-Commit Script

A web interface is nice, but opening a separate browser window is cumbersome, as is synchronizing your patches and code updates with the relevant issues. Subissue will provide a pre-commit script for direct integration with Subversion's existing log mechanisms. For the first time anywhere (as far as I know; please correct me), you can commit your change and resolve your issue (and perform many other operations) in the same step.

Resources, and How To Get Involved

I always have found it easier if one semi-intelligent person (me) at least writes an initial code-base before hoards of people start hacking. But I eagerly await comments and discussion of the potential short-falls, feature ideas, scope, and design of the project. So, join the mailing lists (only the dev list is currently active), and get involved. Once I have collected enough information and have started writing the interface code, I'll open up the repository and allow anyone (with permission) to hack away.

Subissue is an Open Source project, and is intended to remain free for all to contribute, modify, and adapt. Preliminarily, code will be released under the GPL, unless suggestions are made as to why code should be developed under another license (perhaps the same license as or one compatible with the license used by the Subversion project, in hopes that this project could eventually be merged into the general Subversion community process).

Links to Similar Projects

Of course, there are countless other Issue Tracking projects already available. To list just a few (especially the ones from whom Subissue has taken inspiration):

• Bugzilla
• Scarab
• SourceCast and specifically the IssueZilla sub-project, used by other tigris.org projects
• The Debian Bug Tracking System, especially the email-based headers employed by that system

The major problem with each of these systems, and of the others I have seen, is that they (1) require additional setup and maintanence, and (2) separate the issues from the source where they really belong. There are complete source- and issue-tracking solutions, such as SourceCast, available, but I have seen none that are available for free (as in speech or beer). Using Subversion as a base, Subissue inherits most of its required functionality for free (as in, um, somebody else did the work). Subissue intends to evolve into a complete, enterprise-ready, and integrated issue-tracking solution.

Development Progress

Limitations and Issues

Issues with Subissue? Yes, it's true. So far this web page contains mostly wish-lists. While I expect the layout, headers, and issue specifications to remain fairly stable, the web-based interface and pre-commit script will likely not. This is mostly because I don't know how they are going to really work yet.

In particular, the pre-commit script's functionality probably won't even be implemented as a pre-commit script, since Subversion's hooks aren't allowed to modify transactions (only read from them). It may end up being a wrapper to the real svn command, but then issues arise regarding how to deal with failed commits, and the wrapper would need to in fact know about the semantics of each command. Maybe things will turn out that it ends up as a patch to the normal svn client; but then other clients (RapidSVN) cannot benefit from Subissue in the same way. As you can see, there are many potential courses, and all seem to have shortcomings.

Fortunately, at least the web-based interface is likely to be doable in the near future. Others have already built web-based interfaces to Subversion, and this would really be no different at a basic level.