We use version numbers extensively to inform the client infrastructure point of contact about the particular version of file going in during a particular release. Hence these version numbers form the core part of any communication.
We already have a tagging/ branching system in place. - Swaroop On Tue, 1 Mar 2005 09:48:57 -0500, Russ Sherk <[EMAIL PROTECTED]> wrote: > Why are you using these rel nums? CVS auto generates these version > numbers. The length of the version number must grow when branches are > made so that cvs can track multiple versions of (base) versions of a > file. > > There really should only be a few scenarios which require direct use > of the cvs version numbers. > > To simplify, it is advisable implement a tagging/branching system in > your repository. Have a look at the cvs howto tags and branches > section. There is a really good conceptual diagram of how tags work > with the rcs version numbers. The history will always be preserved > (it is the nature of cvs; everything is versioned). > > Creating a fresh root won't solve your probelm in the long run. > > Cheers, > > --Russ > > > On Tue, 1 Mar 2005 11:14:08 +0530, Swaroop George > <[EMAIL PROTECTED]> wrote: > > Hi, > > I am experiencing a peculiar problem. Ours is a huge project and had > > multiple enhancement versions going in since live. Inaddition, we have > > monthly maintenance release as well as patch releases on an as needed > > basis. All this led us creating multiple branches to the code base. > > And the version numbers have now become as long as 1.2.2.1.2.1.2.1 and > > quite cumbersome to handle. > > > > - Is there anyway of alternate versioning and making it much more > > simple, but still maintaining the history to an extent. > > - How about creating a fresh root after archiving the current code to a > > backup? > > > > Bright ideas are welcome.. > > > > Thanks in advance > > Swaroop > > > > _______________________________________________ > > Info-cvs mailing list > > Info-cvs@gnu.org > > http://lists.gnu.org/mailman/listinfo/info-cvs > > > _______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs