CVS and divergent development (long)
Ivan Peters
ivanp at mc.UUCP
Thu Jun 6 23:05:22 AEST 1991
In article <1991May22.200442.20734 at ccad.uiowa.edu>, emcguire at 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 at mc.UUCP (Ivan Peters)
Subject: CVS-RCS
Message-ID: <1991May21.135016.3671 at apertus.uucp>
Sender: news at apertus.uucp (0000-news(0000))
Reply-To: apertus!ivanp at 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 at mc.UUCP (Ivan Peters)
Subject: Re: CVS-RCS
Message-ID: <1991May29.133402.6114 at apertus.uucp>
Sender: news at apertus.uucp (0000-news(0000))
Reply-To: apertus!ivanp at tenfwd.uci.com
Organization: Apertus Technologies
References: <1991May21.135016.3671 at apertus.uucp> <1076 at isgtec.UUCP>
Date: Wed, 29 May 91 13:34:02 GMT
In article <1076 at isgtec.UUCP>, robert at 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 at 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. :-) !!!
More information about the Comp.unix.misc
mailing list