Associating bugs with changesets

[Greg Ward]

On Tue, Jun 2, 2009 at 3:09 AM, Arne Babenhauserheide <arne_bab at web.de> wrote:
> Why don't you use a simple flat file in the repository which contains the
> corrections?
>
> Something like
>
> ------ .bugID_corrections ------
> 094be09b1c5dcd917436beebd0be3e24ea0d31db      52313      52131
> ------ ------ ------ ------ ------ ------

Interesting idea.  The simplicity appeals, but there are a couple of problems:

* we're planning a multi-repository workflow, with all changes
eventually landing in a master repository.  Corrections would take
some time to propagate to all repositories, so different people will
have different changeset/bug mappings at different times.

* some of the difficulties with .hgtags would reappear: specifically,
I'd either have to iterate over all heads to assemble the canonical
set of corrections, or only allow corrections on default (and even
then there's still the possibility of multiple heads).

> You could also go a step further and allow rewriting of the whole commit
> message for QA via this file.
>
> To make the whole process faster, the commit message for the change in the
> correction file could contain the information about the changes. That way you
> could use the correction file for full message rewriting and the commit
> message *of that correction* for the concise information for QA (node A
> doesn't fix bug B but bug C).

Probably overkill.  Typos happen all the time in commit messages, but
I don't worry about them *unless* they have semantic significance...
like misleading QA about what bugs are fixed in the latest build.

Greg