info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Tagging


From: Larry Jones
Subject: Re: Tagging
Date: Thu, 14 Feb 2002 11:34:26 -0500 (EST)

address@hidden 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]