>--- Forwarded mail from [EMAIL PROTECTED] >> > 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 [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs