For a few months now I've been using SD for tracking bugs in many of my personal projects. SD is a distributed bug tracker, and I believe such systems to be the future, just like distributed version control has become the obviously correct choice.

Distributed bug tracking is still in its infancy, and the tools are still developing. However, SD, at least, is already usable, at least for the small kinds of projects as mine are. I have no idea, at least yet, how it scales up to large projects with many developers.

Life with SD is similar to life with a DVCS. You have your bug repository, and you make changes there as find bugs, fix them, and so on. When it is suitable and convenient, you synchronise your repository with others. I mainly sync to my server, so that others can sync from that if they wish. (I don't know if anyone does that.)

There are several distributed bug trackers. I chose SD because it seemed the most mature one, but also because it does not tie the bug repository with the source code version control tree. This is quite important, I think. If there's a bug in the project's website, then that does not need to be committed to the project's source code.

If I work on a bug in a separate code branch, I would like to make any necessary notes about it in a central bug repository for all the branches on my laptop. This is helpful, for example, if I have to back out of my code changes, because I did something stupid, but want to keep the notes I took in the bug repository.

SD is not without its weirdness. The command line syntax is a bit un-Unixy, and it requires setting an environment variable to specify the location of the bug repository. (I wrote a little wrapper script to set it: all my branches for project foo are in ~/foo, and the bug repository is in ~/foo/bugs.) It could perhaps also be faster, but it's not exactly slow, either: it is a joy to be able to just run sd ticket close 123 rather than open a web browser, navigate to the right bug, and click close there.

Also, once you have a bunch of projects, each with its own bug repository, it becomes an effort to synchronise each of them. I'm hoping mr will someday support SD, but until then I'm using a little wrapper that syncs my SD repositories to my server.

I also have a third wrapper that allows me to run an SD command on each repository, so that I can, for example, easily get a list of all open bugs in all projects, which is helpful for my GTD weekly review.

Hey, nice post.
I'm interested in peoples opinions and impressions of SD because I'm developing an alternative called TicGit-ng. I like hearing about other people's perspectives of Distributed Bug Trackers because IMO getting DBTs right is turning out to be harder than you would think.
Some take the route of storing the bugs in with the source code tree as you noted, and others store it in a separate database altogether like SD does (unless I misunderstood how it works). It's turning out to be very subjective, some people prefer one way while other people prefer another way, it seems like there is no one correct way to do a DBT.
TicGit-ng stores its tickets in a separate branch named 'ticgit-ng', and I noticed that you mentioned you didn't want the bugs stored in with the code, I was wondering if you'd had an opportunity to take a look at it? It is still in development, but I think you might find it interesting, and I'd definitely be interested in your feedback :)
Jeff W

Comment by Jeff Sat Apr 2 09:22:26 2011
Jeff, is ticgit-ng specific to git? That would be a show-stopper for me, since I use other version control systems as well, and I don't want my tools to lock me into specific choices in unrelated tools.
Comment by Lars Wirzenius Sat Apr 2 10:29:50 2011