Re: Bug Tracking

[Paul Sander]

>--- Forwarded mail from address@hidden

>> > CVS's support for bug
>> > tracking is poor to nonexistent and many people have commented on
>> > it and requested better support. 
>>
>> That's because CVS is not a bug tracking tool.  It's an archive 
>> system.  Only an archive system.  If you want to do more than just 
>> archiving, you must find tools that do those other things and/or 
>> integrate them yourself.

>Accepting the harsh truth of Mike's statement, may I ask the group whether
>anyone has any particular recommendations or useful script to share which
>can usefully link Bugzilla-stored issues with CVS revisions?  I'm thinking
>along the lines of bug ID's which may be entered into log comments, etc.  

>I can and will write such a thing if need be, but I'm wondering what wheels
>already exist that people can personally endorse.

I've implemented a system where CVS queries the bug database for the
user's open bugs and presents the bug numbers, status, and synopsis
in the commit message template that's fed to the editor.  The user
was expected to edit the list appropriately (i.e. remove all of the
defects except the applicable one) while adding more commentary about
the change.  After the files were committed to the repository, their
RCS file paths, workspace paths, and version numbers were written
to a table in the bug database along with the bug number.  The bug
number was also obviously written into the revision log of each
file.

I did this a long time ago by hacking CVS directly.  Today, you might
get the capability you need from rcsinfo and loginfo.

Using this mechanism, I could not only find out what versions of what
files implemented a bug fix, but given an inventory of files in a build
I could also discover which bugs were fixed in that build.

>--- End of forwarded message from address@hidden