Associating bugs with changesets

[Helmut Stiegler]

Hi,
> 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.
>
>   
You said:

    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.

Actually, if all bugfixes are mentioned in that flat file, as it is 
version controlled itself and merged as all other files are, all bugs 
that are mentioned in the file are solved in that revision. You even 
don't need any reference to a revision (that would require an extra 
commit as .hgtags does).

> * 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).
>
>   
As pointed out above, i would consider the text file just as a list of 
all bugs, that are solved in this revision. Merging revisions to the 
default branch will show the bugfixes there only, when the bugfix itself 
is merged.

maybe this approach may help?

regards Helmut

...
>> 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
>
> _______________________________________________
> Mercurial mailing list
> Mercurial at selenic.com
> http://selenic.com/mailman/listinfo/mercurial
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://selenic.com/pipermail/mercurial/attachments/20090611/05ad42b8/attachment.htm