Associating bugs with changesets

[Greg Ward]

On Mon, Jun 1, 2009 at 4:02 PM, Stephen Rasku <mercurial at srasku.net> wrote:
> 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.

That addresses a different problem: "how do I know which changesets
were motivated by this bug?".  That is a goal for us, but not the
primary goal.

What we *really* need to do is answer "which bugs are fixed in this
build?".  That tells QA what bugs they have to verify, it tells
documentation what bugs need to go in the release notes, and
ultimately it tells our customers why they want this upgrade.

In principle, all that's required is a mapping from build ID to the
changeset that was checked out and built.  From there, we could scan
the hg changelog back to the previous build (or whatever the point of
comparison is) and parse commit messages for bug IDs.  But 1) that
could be slow, 2) it requires access to a clone of the repository
(big), and 3) commit messages are immutable.

Hence my desire to store the changeset ID/bug ID mapping in an
external database.

> 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.

That'll never scale.  It is essential that the process be automated.
(Obviously, it requires human involvement to specify which bug(s) are
fixed in a particular commit or push, and further human intervention
to fix errors in that process.  But finding which bugs are fixed in
build X must be automatic.)

> 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.

Right.  And what happens when someone accidentally types

  Bug-1243:Resolved: ...

?  That's the whole problem with putting bug IDs in commit messages.
(Or any other immutable metadata.)

Greg