Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!news.cs.indiana.edu!ariel.unm.edu!cs.umn.edu!kksys!edgar!brainiac!apertus!news From: ivanp@mc.UUCP (Ivan Peters) Newsgroups: comp.unix.misc Subject: Re: CVS and divergent development (long) Message-ID: <1991Jun6.130522.18253@apertus.mn.org> Date: 6 Jun 91 13:05:22 GMT References: <1991May22.164537.30676@ccad.uiowa.edu> <1991May22.200442.20734@ccad.uiowa.edu> Sender: news@apertus.mn.org (0000-news(0000)) Reply-To: apertus!ivanp@tenfwd.uci.com Organization: Apertus Technologies Lines: 218 In article <1991May22.200442.20734@ccad.uiowa.edu>, emcguire@ccad.uiowa.edu (Ed McGuire) writes: |> I understand how CVS supports divergent development in the sense |> that programmers can modify copies of the code concurrently, the |> result being a set of divergent descendants from the original code. |> That is exactly why we use it. |> |> The difficulty is that a descendant must be brought up to date with |> respect to the repository before it may be committed. What is |> wanted is the capability to manage divergent descendants in the |> repository itself. We wish to copy out an earlier version of the |> code, modify it, and commit the changes to the repository: not as |> the new current source code, but as a variant, descending from the |> earlier version. |> |> This capability is analogous to RCS branches, but at the level of |> CVS tags, not RCS revision numbers. |> ... |> |>I will be grateful if someone can either point out my ignorance of |>an existing capability in CVS to manage divergent descendants, or |>suggest approaches to extending CVS to provide this capability. ... This sounds like the same question I posted on comp.software-eng. (I also did a follow up clarification which I did not include here) I have been testing CVS to try to use it for Config managment. Currently our place uses mainly SCCS with a scattering of RCS. (I do have the csh script to convert from SCCS to RCS.) I found the same limitation with CVS and thought I was missing something. The comp.software-eng group (Many thanks to them!!!) confirmed the limitations that I encountered. I did not know of this same thread here until Mr Phillip Merrick informed me. (If you find this useful, at all, you can thank him for bringing this thread to my attention.) I shall include (what I consider) the main messages from comp.software-eng which show my current findings, and follow with a update/conclusion... =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= Article: 4471 of comp.software-eng Newsgroups: comp.software-eng Path: apertus!news From: ivanp@mc.UUCP (Ivan Peters) Subject: CVS-RCS Message-ID: <1991May21.135016.3671@apertus.uucp> Sender: news@apertus.uucp (0000-news(0000)) Reply-To: apertus!ivanp@tenfwd.uci.com Organization: Apertus Technologies Date: Tue, 21 May 91 13:50:16 GMT I am looking over CVS, a system that is a add on to RCS (a configuration management system) and I have a question I hope someone would please answer: How does CVS support (or does CVS support) dual derivations? example: If someone is deveolping on release 2, of something, and someone else is developing on release 1. How does one make release 1.1, 1.2, etc, (a branch) while allowing work to continue on 2.1 2.2? These releases contain multiple files and sub-dirs. (assume test is the top directory in the repository) One can tag a release. (cvs tag -rTEST2_0 test) One can checkout a release. (cvs co -rTEST1_0 test) One can update from a release. (cvs update -rTEST1_0 test) One can not check in a release, other than the most current. (cvs ci *) Is there a easy process that I am missing? How do others do it? I would like to avoid making a new dir under the repository for each release to be worked on if possible... Any help would be REALLY APRECIATED!!!!! Thanks in advance. :-) Article: 4597 of comp.software-eng Newsgroups: comp.software-eng Path: apertus!news From: ivanp@mc.UUCP (Ivan Peters) Subject: Re: CVS-RCS Message-ID: <1991May29.133402.6114@apertus.uucp> Sender: news@apertus.uucp (0000-news(0000)) Reply-To: apertus!ivanp@tenfwd.uci.com Organization: Apertus Technologies References: <1991May21.135016.3671@apertus.uucp> <1076@isgtec.UUCP> Date: Wed, 29 May 91 13:34:02 GMT In article <1076@isgtec.UUCP>, robert@isgtec.UUCP (Robert Osborne) writes: |> |> Hmmm, seems to be correct. I think the only way to do this is either: |> 1) use rcs directly ****** :-) **** |> 2) use the checkin script |> 3) change 'cvs ci' so it takes the tag just like all the |> other commands (ie. change the current argument -r to -F |> and -rTAG would check into the branch defined at that |> symbol) |> |> I'll look into 3), it might be fairly simple to do. If Brian Berliner |> is reading this maybe he has some input on this question, Brian? |> |> Rob. |> Robert A. Osborne ...uunet!utai!lsuc!isgtec!robert or robert@isgtec.uucp (1 above), looks like the current winner (for our implementation anyways). Thanks for the input, the four alternatives I was looking at were the three listed above, and seperate dirs per release. Would love to hear of developments along 3. I have looked for the same thing in the code as TIME permits, and have not found it as yet. :-( standard key word, time. My current experimentation has lead to a config managment scheme as follows. Hopefully this is useful to someone else... ************************************************************* assume taging convention of Ra_b_c relates to release a.b.c (R1_3_1 = 1.3.1) (This means over all release of multiple files...) =========================================================================== for creating a development release 3.0 from 2.* =========================================================================== cvs co test ; creates work environment for ; compiling vi xx.h ; change and test file(s) vi xx2.h ; change a 2nd file cvs update ; a cvs ci will ask for a ; update if anything has been ; changed cvs ci * ; will checkin all updated files in ; current dir only, to top level. ; so may have to do this step mult ; times to get mult dirs ----- single person from here on -------- {option, cvs ci -r3.0 *} ; bumps revision numbers to 3.0 on ; all files, for major release ; PLEASE NOTE: no consistency check ; so must be done in serial. cvs tag R3_0 test ; freeze code, a release,R3_0 made. =========================================================================== for creating a support release 1.5.1 from 1.5 (.0) =========================================================================== cvs co -rR1_5 test ; creates work environment for ; compiling co -l -rR1_5 $CVSROOT/test/xx.h ; rcs co with lock mv $CVSROOT/test/xx.h . ; darn rcs dir limitation vi xx.h ; change and test the file cp xx.h $CVSROOT/test ; darn rcs dir limitation ci -nTEMPSUPPORT $CVSROOT/test/xx.h ; rcs ci with tag TEMPSUPPORT ----- single person from here on ------ cvs tag -f -r R1_5 R1_5_1 test ; tag all R1_5 with R1_5_1 cvs tag -f -d -r TEMPSUPPORT R1_5_1 test ; del 1_5_1 tag from all changed files cvs tag -f -r TEMPSUPPORT R1_5_1 test ; switch all temp tags to 1_5_1 cvs tag -d TEMPSUPPORT test ; remove temp tag from ALL files =========================================================================== This is just a basic procedure for implementation of CVS and RCS. There are some other frills unused as yet, (modules) . ************************************************* Any optimizations would be apreciated. I have already tried to reduce the fun and games with taging at the end, but tag will overwrite older tags with same name. The 'darn rcs dir limitation' can be overcome by a symbolic dir link, haven't considered the implications as yet. This (the support track) will curently reduce to three scripts, one for checkout, one for checkin, and one for taging all files related to one target. I have not generated the scripts yet, am still looking for alternatives/ researching. If you find this helpful, I wouldn't mind knowing about it... alternative processes would also be appreciated. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+= My current opinion of the options, with CVS were: 1) Use a subdir under CVSROOT per release/branch... This was the first alternative that I found, but would involve much duplicate code, and a possible divergence/merging problem. 2) 2nd pursuit: Useage of cvs ci -rx.x.x.x.... Was not consistent or controlable, since CVS does no consistency checks. Totally unusable except for mentioned above. 3) 3rd: Look at the CVS code, and path the ci process.... This would be the best, if I was given the TIME to find the right place! I gave the code a 30min scan, but was unable to find it and so I had to continue. What my current change would be (which is just my opinion, and since hasn't been implemented, may not be the best) to have CVS check what version of all the local software currently here "cvs update -rREL2_0 means 2.x revs on all software) and when the cvs ci * is performed, it would maintain the highest number of the revsion, and just add to the current branch 2.x.x.x. This would be the same identical mechanisim, as currently used where cvs ci * goes to a.x.x.x, but would use the first digit, that is already stored in ones CVS-ADM local dir. (just my initial thought) 4) Use rcs directly.... Was final winner, with process stated above. 5) use cvs checkin, and join, and treat branches as vendor releases.... The way I envisioned this evolved into 1) again, with its problems, and the additional problem of useing some lessor used parts of CVS, Join and checkin, which I did not think was the intention of CVS. So I did not spend much time on this one... +=+=+=+= I hope this is useful, good luck, and any improvements on anything stated would be aprecieated, or further info also as to how you do it. :-) !!!