Rather than bothering with setting up and maintaining external tools, I usually prefer to simply have a TODO file in my repository where I collect issues and ideas. However, I’m starting to want more of an ability to maybe attach certain metadata, categorize issues etc.
There is ciss-tracker, which is basically a command line interface on top of a plaintext file like I’m already using, and I’m currently playing around with it.
Then there are these “distributed bug trackers”, an idea I find quite interesting. Unfortunately, it doesn’t seem to have a lot of traction. Most tools aren’t actively developed.
Most trackers store their issue database in the repository itself, in a hidden directory or file. Some git-specific tools use a separate branch. I much prefer the latter approach. I think if you were to add native support for bug tracking to a DVCS, you’d want to use a separate storage area. git’s branches allow you to simulate this somewhat.
- I’m not cluttering my source’s history with the bug data. The two seem like distinct things. You can get a log for only the bug changes.
- Merging the bugs would be separate from merging the source tree, making it easier to implement a custom merge code specifically for the bug tracking part. Different from source code, conflicts could be resolved by a command line tool asking the right questions.
- You also have only a single bug database for the repository – something like github could easily base their web bug tracker UI on the repository storage. And you could still have the ability to link bugs to individual branches.
Update: There’s also Simple Defects, which has a unique approach: Instead of trying to build on a DVCS, it’s a completely self-contained system, though there is at least some basic git-integration.
Interesting posts on the subject: