Swaroop, It is not clear from your message why you need to use the rcs version numbers. If you are already using tags then you seem to have missed the point of why they are useful. I can't imagine a reason why you couldn't just tell somebody the tag name and have that be good enough. Maybe I just don't understand what you are trying to do, however.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Swaroop George Sent: Wednesday, March 02, 2005 5:47 AM To: Russ Sherk Cc: [email protected] Subject: Re: Long version numbers | Tedious to keep track 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 > > [email protected] > > http://lists.gnu.org/mailman/listinfo/info-cvs > > > _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [email protected] http://lists.gnu.org/mailman/listinfo/info-cvs
