Associating bugs with changesets

[Greg Ward]

Hi all --

I'm sure we're not the only organization that needs to associate
changes with bugs in our bug database.  Our current CVS-based workflow
does this in the obvious way, by prefixing checkin comments with
"bugNNNN: ".  The big problem with this is that developers are human
and humans make mistakes, and when someone commits bug 23235 as bug
23253, that cause problems down the line.  (Like, when QA is querying
the database that results from those checkin comments, they think the
latest build fixes bug23253 rather than bug23235.)

My preferred solution would be infallible developers who never make
mistakes.  I'm still waiting for management to get back to me on that
one.  So what we do instead is use "cvs admin" to rewrite the checkin
message if we catch it soon enough, or just live with it if not.

Obviously this won't port to Mercurial, or to any other VC system with
immutable checkin messages.

So, I'm wondering how other people handle the whole issue of
associating changesets with bugs.  I'm pretty sure an external
database that maps changeset ID to bug ID is an important part of the
picture: it'll be faster and easier to query than the Mercurial
changelog, and it will be possible to fix the inevitable human errors.
 But I have some questions for people with direct experience:

  * When to populate this database? commit time seems like a bad time,
since 1) people can override hooks and 2) people can throw away local
commits. So I think it should be done when changes are pushed to a
central repository.  Other ideas?
  * How to display the mapping?  Human error means the bug ID should
not go in the commit message stored in Hg's changelog. But *boy* is it
ever useful to see bug IDs when browsing history.  So it would be neat
to have an extension that queries the changeset/bug mapping and sticks
the "bugNNNN: " prefix into the commit message when browsing history.
Has anyone tried implementing such a beast?
  * How to distinguish between "this changeset is ongoing work for
bugNNNN" and "this changeset fixes bugNNNN, at least to the best of
the developer's knowledge and ability"?  Adding a field to the
changeset/bug mapping, but how does the developer express this?  Add
options to push: "push --fixes NNN --ongoing MMM"?  Ideas?

Thanks --

Greg