[EMAIL PROTECTED] writes: > > Question: My production system is set to be released/baselined at the > annual level. However, changes after the annual release are frequent. > Some of these changes are minor(cosmetic) but some may require deletion or > addition of code or even whole re-writes of code. Am I correct in thinking > that I should have the developers use tags for minor changes(excluding > cosmetic changes) and then use rtag for my release version?
You almost never want to use rtag. If you don't specify an existing tag or a date, you have no idea what you're tagging. In general, you want to check out a working directory, make sure it's exactly what you want to tag, and then use tag to do so. You need to say a bit more about the changes after the annual release. Are there bug fixes/enhancements that are sent to customers (e.g., update or point releases), or just new development that won't be shipped until the next annual release? If you have both bug fixes that get shipped quickly and new development that doesn't get shipped until the next annual release, you'll want to make a branch off the annual release for the bug fixes and do the main development on the trunk. You'll want to tag each point release on the branch, and you'll probably want to merge the changes from the branch to the trunk periodically (at least at each point release, but perhaps more frequently). If nothing gets shipped until the next annual release, then you can do all the work on the trunk, and there may well not be any reason to track the individual changes with tags at all. > This scares > me..typically the way we have done things in the past was to have multiple > copies for each year(i.e. dir for 2000, dir for 2001,etc). Should I just > set up a main repo and rtag it for each year instead of having creating > multiple repos for every year? A single repository with tags for each release is almost certainly the right way to go. -Larry Jones Some people just don't have inquisitive minds. -- Calvin _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
