On last week's Development page we looked at the
Fossil version control system, with one of its distinguishing features
being the inclusion of distributed bug tracking as part of the tool. Another
distributed bug tracker has recently come to our attention, and
that is Simple Defects, or SD for
short. There are a number of different distributed bug trackers out there,
with Bugs Everywhere seeming to
hold the role of "leader of the pack", but a brief introduction to SD seems
So far, distributed bug tracking (DBT) hasn't taken off quite like
distributed version control systems (DVCS) did, but there is still a fair
amount of interest in the idea.
In some ways, it feels like the DBT communities are still feeling their
way, much like the pre-2005 DVCS world, and that at some point, the right
combination of features will come about in one or more projects (much like
the broadly similar feature sets of Git, Mercurial, and Bazaar did). Once
that happens, DBT may find its way into more and more projects.
The basic idea of DBT is that centralizing bug tracking on one system makes
it difficult for disconnected developers to easily handle editing bugs
while they are fixing the code. There are (at least) two ways to approach
the problem, either by somehow keeping the bug reports and code in the
same repository (which is Fossil's approach) or by having a separate
repository for bugs that can be synchronized in ways similar to that of a
DVCS (the approach of SD and Bugs Everywhere). The latter approach has the
advantage of being able to work with multiple version control systems, but
it has the disadvantage of requiring developers to manage their code and
bug repositories separately.
SD is written in Perl to sit atop the Prophet distributed
database. Both Prophet and SD are available on the Comprehensive Perl Archive Network (CPAN),
but the developers recommend getting them from the Git repositories if
possible due to the rapid development pace. The development logs seem to
bear that out as there hasn't been a release since Prophet
and SD 0.7 in August 2009—though there seem to be more recent
CPAN updates—while the Git logs show progress as
recently as early March.
One thing that can't be said for SD (or Prophet) is that they are overly
burdened with documentation. That may tend to chase away potential users,
but the terse Using SD page does
cover many of the topics that users are likely to be interested in. The
should be familiar to anyone who has used a DVCS, as you clone a ticket
$ sd clone --from http://example.com/path/to/sd
or initialize a new repository with:
$ sd init
As with Git et al., you synchronize from a remote repository with a
pull sub-command, and update remotes using publish
(instead of Git's push). Bug
tickets are created with the unsurprisingly named:
$ sd ticket create
command, which opens your text editor with a template to create the bug.
There are, of course, various commands to search and update bugs, as well.
sub-command will put SD into server mode and start up
a web browser to
search and edit bugs.
SD also provides ways to synchronize its bugs with other systems like Trac,
GitHub, Google Code, Hiveminder, RT, and others.
Overall, it seems like an interesting system for projects that are looking
for a simple DBT that doesn't combine code and bugs into a single
repository. That is one of the advantages of SD, at least for Lars
Wirzenius, who made the blog post that introduced us to SD. He also notes
that it seemed to him to be the most mature of DBT systems currently, which
is a little surprising given the status of Bugs Everywhere. The ability to
handle bugs from the command line is another advantage that he cites.
The lack of documentation is somewhat intimidating, and overall the
projects could use a bit of work on their web sites. The wiki is largely a
placeholder, and the project pages have just the bare essentials. In fact,
for Prophet, even the bare essentials appear to be lacking, which is
unfortunate as the description sounds intriguing: "Prophet is a new
kind of database designed for the post Web-2.0 world. It's made to let you
collaborate with your friends and coworkers without needing any kind of
special server or internet provider." It sounds like something that
might prove useful to projects like the Freedom
While SD and Prophet may still have quite a ways to go before being ready
to handle larger projects or ones with different needs, they do currently
work for some projects. For Perl programmers with an interest in DBT (or a
distributed database), they might provide a nice opportunity as a project
to contribute to. For others who just want a simple DBT to use, its
probably worth taking a peek at SD.
to post comments)