info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tags usage -- comments please


From: Todd Denniston
Subject: Re: Tags usage -- comments please
Date: Mon, 14 Jun 2004 11:49:28 -0500

"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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]