I would keep one repository, for starters, and use tags to identify releases. There are many different ways of managing them, and I would refer you to http://www.enteract.com/~bradapp/acme/branching/ and Karl Fogel's book (relevant chapters of which can be found at http://cvsbook.red-bean.com/, particularly the section on working with branches.)
One approach would be to do minor changes directly on the mainline but to have branches for major rewrites, remembering to merge early and often and labeling as necessary. Dave -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, February 14, 2002 9:21 AM To: [EMAIL PROTECTED] Subject: Tagging 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? 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? _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
