CVS and divergent development

[John Sully]

emcguire at ccad.uiowa.edu (Ed McGuire) writes:

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

Here you can also do:

      $ cvs tag -r1.9.1 1_1A $CVSROOT/src/Makefile,v

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

You can also use the cvs "join" command to accomplish the same thing:

>     % cvs update          [copy out current version]
>     % rcsmerge -r1.9 -r1.9.1.1 $CVSROOT/src/Makefile,v Makefile
>			   [merge changes into current version]
      $ cvs join -r1.9.1.1 Makefile
>     % 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.

You don't really have to go behind it's back, but it is more difficult 
than it should be.  It would be nice if CVS had a way to manage branches
more easily.

Along these same lines, I have written several scripts which help with
tagging and managing what we refer to as "twigs". One walks a checked
out source tree and tags the proper revision of each file with a given
tag.  It also reports on any files which you may have forgotten to checkin,
The other will walk a checked out tree and merge "twigs" back into the
trunk in a manner similar to the above method.  This helps a little, but
the functionality of both of these scripts should be placed in the CVS
command itself.

Do other people out there using CVS have any ideas for enhancements or
pet peeves?  I've done quite a bit of work on it here and am interested
in hearing from other people who have been using it.

--
John M. Sully                      
Unisys Corporation                 
2700 N. First St.                  
San Jose, CA 95150                 
                                   
Phone : (408) 435-3129             
E-Mail: jms at unix386.convergent.com