RE: Long version numbers | Tedious to keep track

[Mark Priest]

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: address@hidden
[mailto:address@hidden On Behalf Of
Swaroop George
Sent: Wednesday, March 02, 2005 5:47 AM
To: Russ Sherk
Cc: address@hidden
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 <address@hidden> 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 
> <address@hidden> 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
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/info-cvs
> >
>


_______________________________________________
Info-cvs mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/info-cvs