>--- Forwarded mail from [EMAIL PROTECTED] >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? By all means, use tags. But adopt a naming convention beforehand. >> 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. It happens often enough when you want to port a specific bug fix to a new branch. >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. I have also seen situations where someone is given a list of files with version numbers, wanting a list of bug fixes that were implemented with those files. (The list was a diff between reduced output of "cvs status" in two baselines. The result was used by Q/A to focus their efforts.) However, without help from the defect tracking system, this also involves using "cvs log" to pull the necessary info from file histories. >--- End of forwarded message from [EMAIL PROTECTED] _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
