Scmbug helps write software in a disciplined way. [1] It ties what changed in the software source code with why it changed.

This helps establish a software change management process. Scmbug connects a source code version control system with an issue tracker, and this connection helps track changes, plan what to work on next, and trace problems back to their root.

The most noticeable change in the workflow is that Scmbug rejects source code commits that are (a) missing a bug number in the commit log, and that are (b) issued against bugs one shouldn't be working on. Rejecting commits is instant. I get an error right away if I'm changing software when I'm not supposed to.

If it feels somewhat silly to use software that forbids you from writing software, know that it feels less silly than not remembering what you were thinking when you first wrote the software. I make many decisions I soon forget when I'm programming and at some point I can't tell how to backtrack or what to do next.

With Scmbug I find my way back. It leaves a trace back to why I wrote each line like Theseus left a thread back to the entrance of Minotaur's labyrinth. It also leaves a trace towards the opposite direction. For each bug I file, Scmbug inserts commit logs in the bug as comments so I know what changed in the source code to fix it.

Scmbug can't always protect a change management process from developers who try to subvert it. It can't help if you commit changes for separate issues against the same bug number. But it catches honest mistakes. If you want to write software in a disciplined way, Scmbug gets you halfway there.

There are two parts to Scmbug. Integration glue is added as hooks in the source code version control system like CVS, SVN and Git that lets Scmbug control commits. The glue talks to a server daemon to integrate with an issue tracking system like Bugzilla, MantisBT, and RequestTracker.

The latest version 0.26.22 is available here, there is a user manual [HTML single] [HTML multiple] [PDF], and an issue-tracker [2].

Scmbug now has enough of the features one needs that I haven't worked on it in a long time. Many companies installed Scmbug at the time I was writing it.

Neither DynAMOS, nor UpStare, nor Scmbug itself would exist without the first version of Scmbug.


[1]  Discipline isn't as helpful when starting to write the software. If you're just exploring ideas it's better to indulge in what seems interesting even if you don't know why. Discipline is helpful later, after a direction becomes clear and there's a lot to do.

[2]  I disabled the issue-tracker. The reason why will sound old news, but it was because of a bad software update. The web server stopped running Bugzilla and I couldn't fix it within 5 minutes.

If software can't stay alive on its own, will it be around in the long run?