I’ve been using ditz for a few months now. It’s a bugtracking system like trac or bugzilla except that it doesn’t run in a centralized server. Instead, it lives as a bunch of text files inside your SCM.

Ditz is written in ruby, and it uses yaml files to store all the issues (tickets) and groupings of issues. Ditz allows issues to be grouped into releases.

$ ditz releases
0.6 (unreleased)
0.4 (released 2008-07-27)
0.5 (released 2008-08-20)

I wrote an extension that would show all the issues attached to a particular release, like this:

$ ditz help ri
Show issues for a particular release.
Usage: ditz ri

$ ditz ri 0.6
x ditz-61: Use text editor for multiline input where possible.
x ditz-72: add model object post-creation validation
x ditz-71: 'ditz add' shouldn't ask for comments
x ditz-76: allow configuration of whether the editor is used or not
x ditz-69: Store issues in .ditz directory by default
_ ditz-42: support tiny issue identifiers (like #34) in the single-component case
x sheila-1: check for a "git push" having updated the issue db, and reload if so
.... lots more issues snipped for brevity.


Thanks to all the really neat plumbing already built into ditz, my patch was trivial to write:

operation :ri, "Show issues for a particular release", :release do
end
def ri project, config, opts, release
puts todo_list_for(release.issues_from(project))
end


Ruby is a pretty neat language and people do neat stuff with symbols. In that code above, the operation method takes the symbol :ri and effectively decorates my ri method with the help text. I’m really impressed by how ditz took the fact that my ri method takes a :release symbol as a parameter, and because of that, it knew how to search in the list of releases and then give me the relevant release.