CVS and divergent development

[Ed McGuire]

In article <1991May25.011338.3040 at m2xenix.psg.com> randy at m2xenix.psg.com (Randy Bush) writes:
>And, to add one more level of complexity to the problem,
>1.1.* is the released version
>1.2.* is where we're hacking
>A bug appears in the relased version.  We want to
>  o fix it in 1.1

We tagged the original released version as "1_1".  This permitted us to
copy out by tag.  We fixed the bug and committed the affected file(s)
with explicit RCS revision numbers to create branches.  Example:

     % cvs co -f -r1_1 src       [note Makefile revision is 1.9 for commit]
     % vi Makefile
     % cvs ci -r1.9.1 Makefile   [commits as 1.9.1.1]

>  o reissue 1.1, and

We tagged the fixed version as "1_1A" (version 1.1A).  This was
accomplished by applying the new tag to the same revisions identified
by "1_1", then fixing the tag in those files which we edited.  Thus
"1_1A" identified the version to be reissued.  Example:

     % cvs tag -f -r1_1 1_1A src                    [once]
     % rcs -N1_1A:1.9.1.1 $CVSROOT/src/Makefile,v   [once per changed file]

>  o have the fix mergable forward to 1.2.

We used "rcsmerge" to merge the differences between the "1_1" files
and the "1_1A" files with the current (1.2) version.  Example:

     % cvs update          [copy out current version]
     % rcsmerge -r1.9 -r1.9.1.1 $CVSROOT/src/Makefile,v Makefile
			   [merge changes into current version]
     % cvs ci Makefile     [commit version with changes]

In fine, we can get the job done but we have to go behind CVS' back
to accomplish it.
-- 
peace.  -- Ed
"Over here, Bones!  This man's dying!"
"Damn it, Jim!  I'm a doctor, not a . . .  What did you say?"