Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!europa.asd.contel.com!wlbr!voder!pyramid!ctnews!unix386!jms From: jms@unix386.Convergent.COM (John Sully) Newsgroups: comp.unix.misc Subject: Re: CVS and divergent development Message-ID: <7737@unix386.Convergent.COM> Date: 4 Jun 91 15:02:17 GMT References: <1991May22.164537.30676@ccad.uiowa.edu> <1991May22.200442.20734@ccad.uiowa.edu> <1991May25.011338.3040@m2xenix.psg.com> <1991May28.195139.19749@ccad.uiowa.edu> Organization: Unisys/Convergent, San Jose, CA Lines: 72 emcguire@ccad.uiowa.edu (Ed McGuire) writes: >In article <1991May25.011338.3040@m2xenix.psg.com> randy@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@unix386.convergent.com