Re: Long version numbers | Tedious to keep track

[Swaroop George]

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
> >
>