On Mon, 21 May 2001, Paul M Foster wrote:
> CVS assigns rev numbers on the order of 1.1.2, 1.2.1.1, etc. My
> experience has been that in the process of developing a project I have
> various files of various CVS-assigned revision numbers. When I finally
> get to a release point, I have to figure out a way to know that
> version of 1.1 of this file, 1.3 of that file, etc., all equal my
> public release of "Version 3.2". It seems that assigning cvs "tags"
> might be a possible solution, but tags must start with a letter (not
> "3.2"). Or you could tarball each major public version, but that kinda
> defeats the purpose of CVSing things.
>
> So I'm wondering, in real production environments, how do project
> admins track this and keep everything straight (when using CVS)?
Here's the kind of thing I do at Nielsen Media Research (I'm the Change
Management guy):
CVS tags can not start with a letter, nor can a period be used in the tag
name. Our releases, therefore, are tagged similar to:
release_4-5-1
release_5-0-0
Additionally, when we branch code for a release (say, the 4.5 series) I
tag the trunk with
root_of_branch_4-5
and create a branch from that point called
branch_4-5
Releases on that branch are tagged with
release_4-5-0
release_4-5-1
release_4-5-2
Now, when it comes time to merge a release into the trunk I will do the
merge, commit everything, then tag the trunk with
merged_4-5-1
to let me know what I have merged.
Anyway, this is a *short* overview of what we do to keep track of the
mountains of code we use. More information upon request.
Paul Braman
aeon@tampabay.rr.com
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:25:28 EDT