"Jim.Hyslop" wrote: > > Jeeva Sarma wrote: > > In our team, one developer wants to make tags for a few > > files; suppose he is working on 2 bugs, each requiring > > changes in 2 or 3 different set of files, he wants to tag > > each of those 2 or 3 files with the bug number, so that he > > can remember which files are modified for which bug. I think > > this is the wrong way to use tags, not the way they were > > intended to be used. > A tag is intended to mark a file or a set of files as special in some way. > How does your colleague's approach violate this intention? > > > I think log message is a better way to > > use in this case, we can later search the logs for the bug > > numbers. He doesn't agree. Any comments for/against this are > > greatly appreciated. > Locating bug fixes by searching the logs will require you to search all the > logs for all the files. On the other hand, the tags will lead you to the > exact files you need immediately. However, the large number of tags involved > could get unwieldy. > > Let me turn your question around: how often have you had to determine > exactly which files have been affected by a specific bug fix? (This is an > open question to anyone reading this message). I cannot recall ever needing > this information. For me, a few times. more interesting was tracking when something that had not worked was fixed and by which set of changes.
> > If my experience is typical, then I would say use the 'log' approach. If, on > the other hand, your workflows and processes require you to frequently > backtrack this information, then the tag approach may be better. > It could be that most of my repositories were small (<300MB) but I have always found that using rcsinfo & verifymsg to force the inclusion of bugfix numbers and some kind of comment (yes it could be tricked into allowing a non meaningful comment) gave sufficient information, so that using cvs2cl[1] and grep you could find all of the needed information ... date_time of change, all files changed, revisions of each of the files, and comments. of course some coders have this weird thing of wanting to put a different comment on each file for a single change, it is annoying but by forcing the bug number you can deal with it. [1] http://www.red-bean.com/cvs2cl/ -- Todd Denniston Crane Division, Naval Surface Warfare Center (NSWC Crane) Harnessing the Power of Technology for the Warfighter _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs