Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
> Does anyone know whether there is any reason (performance? aesthetics? > morality?) not to use a large number of tags? We build our > project nightly, > and some people have suggested tagging the source after each > successful > build. I have a few comments you might find useful... I did nightly internal releases of my project for several months using a script which automatically tagged the whole module in CVS with the project name, build date, and project version number (my script actually read the project version out of the MS version table in my .rc file to generate the tag name for CVS). It was extremely beneficial to be able to match the version number from the application's "about box" (also suppled from the .rc file's MS version table, just like the tag) to a CVS tag for bug report resolution when we were in a fast development state of publishing daily new releases of the product and were never sure if somebody who reported a problem had the latest version or the one from a couple of days ago. The person reporting the problem could indicate the version from the about box, and I could pair that with a CVS tag and then check to see if that problem had been resolved or not from that version until the present. So I highly recommend nightly build tags. I never noticed any drain on the CVS repository or server or anything. But the status reports and graph reports of my files in WinCVS show so many tags that it becomes hard to get useful information out of those reports without also using the options to suppress listing the tags. My project and its files in general are using mostly just my nightly build tags - there were very few other points in the development process that I felt needed to be tagged - so that's not a problem for me. But if you are using a variety of other tags as well as the nightly tags you are considering adding, you might want to consider that status reports of all the tags on a file might list so many tags that it may become difficult to weed out the tags you are interested in from the nightly build tags. If that's a feature you tend to use. You can always get the equivalent of a tag using a date and time, so if you are doing your nightly builds at the same time every day and can be sure there aren't any commits close to that time, then a tag is redundant with the date and time of the release. However, I was doing releases at any time of day as necessary as something of a hot-fix cycle, so it was important for me to use a tag since I had no way of knowing whether version 1.1 build 110 had been generated at 10am or 6pm on its build date. Hope that helps :) -Ris