[Top][All Lists]

[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.


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]