Re: CVS and tracability
On Sun, Mar 06, 2005 at 02:10:07PM -0800, Paul Sander wrote: >You can also use rcsinfo to prompt the user for a defect ID and use >loginfo to record the modified files and version numbers in your defect >tracking system. Done right, you also get the ability to query for >bugs fixed in a given build. Yup, which can work very well. The CVS - Bugzilla integration work I've done goes a fair way to making this work - see http://www.einval.com/~steve/software/cvs-bugzilla/ for more details. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "...In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver." -- Daniel Pead signature.asc Description: Digital signature ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and tracability
You can also use rcsinfo to prompt the user for a defect ID and use loginfo to record the modified files and version numbers in your defect tracking system. Done right, you also get the ability to query for bugs fixed in a given build. On Mar 6, 2005, at 3:06 AM, [EMAIL PROTECTED] wrote: I'm faced with the requirement to trace changes due to certain bugfixes, i.e. to answer questions like "which files have been affected by change request 1234". Currently, the only way I can think of to answre question like this is using the taginfo mechanism. Are there any examples I could use? Other approaches? -- Paul Sander | "Lets stick to the new mistakes and get rid of the old [EMAIL PROTECTED] | ones" -- William Brown ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: CVS and tracability
CVSNT (also GPL, free, Windows, Linux, Unix, Mac etc) has a -B bug switch for "cvs edit", "cvs commit" etc etc. This can be captured by the various triggers so that each time a commit is done the information is available. You can either "log" the info there, or integrate it directly with your defect tracking system so a log message is applied to it when you commit (this is what we do). You can also cvs commit -b bug to "commit by bug number". You can get cvsnt from www.cvsnt.com and the cvsnt mailing list is here: http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt Or news://news.cvsnt.org/support.cvsnt Regards, Arthur Barrett > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > ] On Behalf Of Familie Moßner > Sent: Sunday, 6 March 2005 10:06 PM > To: info-cvs@gnu.org > Subject: CVS and tracability > > > Hi, > > I'm faced with the requirement to trace changes due to > certain bugfixes, > i.e. to answer questions like "which files have been affected > by change > request 1234". > > Currently, the only way I can think of to answre question > like this is using > the taginfo mechanism. > > Are there any examples I could use? Other approaches? > > Any hints appreciated, > wkm > > -- > www.mossner-online.de > > > ___ > Info-cvs mailing list > Info-cvs@gnu.org > http://lists.gnu.org/mailman/listinfo/info-cvs > ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS and tracability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Familie Moßner <[EMAIL PROTECTED]> writes: > I'm faced with the requirement to trace changes due to certain bugfixes, > i.e. to answer questions like "which files have been affected by change > request 1234". > > Currently, the only way I can think of to answre question like this is using > the taginfo mechanism. > > Are there any examples I could use? Other approaches? You could alter your CVSROOT/rcsinfo to provide a log message template with something like a 'request:' field and enforce good values via the CVSROOT/verifymsg trigger and have your loginfo trigger send e-mail or otherwise attach the desired information of the request found in the log message into your defect tracking system that attached the list of modified files to the request-id. This would let you query your defect tracking system for entry '1234' to obtain a list of files that were impacted on a particular date. Another approach would be to use something like the cvs2cl package to generate xml for all of the changes in a given release and collect the list of files needed from the entries with log messages that reference the interesting bugfix identifiers in a useful way to your own applications. Good luck, -- Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQFCKyEb3x41pRYZE/gRAqHgAJ401IbLhaxuvmhAu49ftt7zuYd9QQCggYUp 08L2n1P3Qe686QoQ/ZxlJbo= =pUS6 -END PGP SIGNATURE- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
