Associating bugs with changesets

[Stephen Rasku]

On Mon, Jun 1, 2009 at 10:17, Greg Ward <greg-hg at gerg.ca> wrote:
>
>  * 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?

I am using the "incoming" hook on our offical repository in order to
post changeset messages to our bug database.  This creates a separate
comment in our bug database.  You could also use "changegroup" which
will only be run once instead of for each changeset.  The difference
is pretty arbitrary but it might be easier to implement "incoming"
than "changegroup".

>  * 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?

I don't know how you are intending on using this so I don't know if
this will apply to you or not:
What I would do is just manually add comments on the relevant bugs.
Something like:  The above message should really be on bug xxxx.  I
could then paste the changeset message manually to the correct bug.

>  * 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?

We were using a convention similar to the following for our commit messages:

Bug-1234: Removed bubble sort.
Bug-1234:Resolved: Bubble sort actually is the way to go.

The resolved tag indicates that the developer actually thinks the bug
is fixed.

...Stephen