Swaroop George wrote:
> 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.
First of all, don't "handle" them. Apply a symbolic tag and refer to that
instead. For the most part, you and I should not know or even care what the
CVS revision number is.
>
> - Is there anyway of alternate versioning and making it much more
> simple, but still maintaining the history to an extent.
I'm almost certain your branching and versioning strategy can be simplified.
It's been my experience that when people create such a complex branch
structure sit down and analyze what they really need (along with an expert
who truly understands branching) the branch and merge process becomes _much_
simpler.
Let's take the revision you supplied. The branch structure for that file is:
[note - view with a fixed-pitch font for best results]
1.1---1.2---1.3---. . .
\
+---1.2.2.1--???
\
+---1.2.2.1.2.1--???
\
+---1.2.2.1.2.1.2.1--???
At each branch point, what exactly was the event that made you decide to
start a new branch? In other words, what does each branch represent?
In each branch indicated, are there any other revisions in that branch
(represented by the ??? in the tree)?
> - How about creating a fresh root after archiving the current
> code to a backup?
What do you mean by "create a fresh root"?
--
Jim Hyslop
Senior Software Designer
Leitch Technology International Inc. ( http://www.leitch.com )
Columnist, C/C++ Users Journal ( http://www.cuj.com/experts )
_______________________________________________
Info-cvs mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/info-cvs
