comp.software-eng archive file "blurb/cvs" last changed 30 Jul 1993 This file contains information on the following subjects. Numbers in column 1 count distinct messages with the corresponding subject. 1 CVS 1.3 release announcement 2 CVS as I understand, and how to create 1.1.2 branch? ------------------------------------------------------------------------ Subject: CVS 1.3 release announcement Date: Mon, 06 Jul 92 13:21:44 CDT From: Brian Berliner Thanks to over 40 contributors from around the world, the CVS 1.3 release is now available. CVS, the Concurrent Versions System, is a front-end for RCS. Some of the features it provides include: - The ability for many developers to work concurrently from the same set of revision-controlled files, in isolation. - Support for "modules", which are named collections of sources. These modules can refer to an entire distribution, or to smaller pieces of a larger distribution. - Modules can be combined to form symbolically named releases. Previous releases can be retrieved and operated on at any time. - Support for RCS branching is included to allow development to be "forked" at any point in time. This can be used to create a patch to a previous release, or to work on an "unknown" change in isolation. - Creating patch-format files for changes made between two releases is as easy as a single command. - Unlink RCS, nearly all CVS operations are recursive, operating on your entire hierarchy of sources with a single command. - Many site-configuration hooks are provided to allow each organization to tailor CVS to their needs. For example, it is possible to configure your site such that only certain people or groups can modify a certain collection of source; or to insist that a particular template be filled out appropriately for each change (including bugid and test verification, say). - Support for specifying free-format dates, as well as symbolic and numeric revisions is provided. This makes it convenient to show all the diffs that have occured in the last week, for example. - A history mechanism is provided to keep track of CVS usage within your site. This is convenient to find out who may be working on a certain module. - A GNU Emacs "CVS-mode" has been contributed and is include with the CVS 1.3 release. Many other interesting scripts have been contributed and are included with CVS 1.3 as well. You can get CVS 1.3 by anonymous FTP to prep.ai.mit.edu in the file pub/gnu/cvs-1.3.tar.Z. No diffs from previous releases have been created, since they would be larger than the full distribution. -Brian From: ttvvtt@mixcom.com (Donald Amby) Subject: CVS as I understand, and how to create 1.1.2 branch? Date: 8 Jun 92 14:30:01 GMT Organization: Milwaukee Internet Xchange BBS, Milwaukee, WI U.S.A. The following is a summary of how I understand that CVS (Concurrent Versions System) and RCS (Revision Control System) revisions operate. +---+ +---+ +---+ |1.1|----------------------|1.2|----------------------|1.3|-... +---+ +---+ +---+ ||\ ||\ ||\ || <1.1.1> || <1.2.1> || <1.3.1> || \ || \ || \ || +-------+ +-------+ || +-------+ +-------+ || +-------+ +-------+ || |1.1.1.1|-|1.1.1.2|-... || |1.2.1.1|-|1.2.1.2|-... || |1.3.1.1|-|1.3.1.2|- || +-------+ +-------+ || +-------+ +-------+ || +-------+ +-------+ | \ | \ | \ | <1.1.2> | <1.2.2> | <1.3.2> | \ | \ | \ | +-------+ +-------+ | +-------+ +-------+ | +-------+ +-------+ | |1.1.2.1|-|1.1.2.2|-... | |1.2.2.1|-|1.2.2.2|-... | |1.3.2.1|-|1.3.2.2|- | +-------+ +-------+ | +-------+ +-------+ | +-------+ +-------+ \ \ \ <1.1.3> <1.2.3> <1.3.3> \ \ \ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ |1.1.3.1|-|1.1.3.2|-... |1.2.3.1|-|1.2.3.2|-... |1.3.3.1|-|1.3.3.2|- +-------+ +-------+ +-------+ +-------+ +-------+ +-------+ The "cvs import" command can be used to initially load a complete directory tree into the repository, and baseline it. It will create revision 1.1, branch 1.1.1, and revision 1.1.1.1. I tried an experiment to verify this behaviour by capturing a directory of some of my tools (/home/amby/tools), into our repository (amby/tools). This was accomplished via the following steps. (1) Set working directory to top of tree to be imported. (2) Import the whole directory tree, defining the following tags. vendortag releasetag_1 releasetag_2 ----------------------------------- begin ----------------------------------- $ cd /home/amby/tools # (1) $ cvs import -m "Don Amby's tools - for testing CVS operations" \ # (2) amby/tools vendortag releasetag_1 releasetag_2 N amby/tools/makefile . . ------------------------------------ end ------------------------------------ This set up the following revision relationships for every file being imported. +---+ |1.1| +---+ \ <1.1.1> <-- "vendortag" \ +-------+ |1.1.1.1| <-- "releasetag1", "releasetag2" +-------+ To verify this, I checked out release 1.1 of amby/tools from the repository, and examined (using cvs status) one of the files. ----------------------------------- begin ----------------------------------- $ cvs checkout -r1.1 -damby/tools/1.1 amby/tools U amby/tools/1.1/makefile . . $ cvs status -v amby/tools/1.1/makefile =================================================================== File: makefile Status: Up-to-date Version: 1.1 Fri Jun 5 14:52:40 1992 RCS Version: 1.1 /scm/master/amby/tools/makefile,v Sticky Tag: 1.1 Sticky Date: (none) Sticky Options: (none) Existing Tags: releasetag_2 (revision: 1.1.1.1) releasetag_1 (revision: 1.1.1.1) vendortag (branch: 1.1.1) ------------------------------------ end ------------------------------------ After having the initial versions established, I then wanted to define another branch off of 1.1 (as 1.1.2), and label it as "SCO". The following is what I did, and the results. (3) Define a symbolic name for the initial version (V1_0). (4) Define a branch for SCO specific changes to V1_0, or so I thought. ----------------------------------- begin ----------------------------------- $ cvs rtag -r1.1 V1_0 amby/tools # (3) $ cvs rtag -b -r1.1 SCO amby/tools # (4) ------------------------------------ end ------------------------------------ I then checked out another version of the amby/tools module from the repository, and examined a single file. ----------------------------------- begin ----------------------------------- $ cvs checkout -rSCO -damby/tools/SCO amby/tools U amby/tools/SCO/makefile . . $ cvs status -v amby/tools/SCO/makefile =================================================================== File: makefile Status: Up-to-date Version: 1.1 Fri Jun 5 14:52:40 1992 RCS Version: 1.1 /scm/master/amby/tools/makefile,v Sticky Tag: SCO (revision: 1.1) Sticky Date: (none) Sticky Options: (none) Existing Tags: SCO (revision: 1.1.0.2) V1_0 (revision: 1.1) releasetag_2 (revision: 1.1.1.1) releasetag_1 (revision: 1.1.1.1) vendortag (branch: 1.1.1) ------------------------------------ end ------------------------------------ I am not sure why the "SCO" tag is revision 1.1.0.2, as I thought that it should have been 1.1.2. How could I generate a 1.1.2 branch, and tag it? From: berliner@rmtc.Central.Sun.COM (Brian Berliner) Subject: Re: CVS as I understand, and how to create 1.1.2 branch? Date: 8 Jun 92 17:51:58 GMT Organization: Sun Microsystems, Inc. In <1992Jun08.143001.3073@mixcom.com> ttvvtt@mixcom.com (Donald Amby) writes: > The following is a summary of how I understand that CVS (Concurrent > Versions System) and RCS (Revision Control System) revisions operate. CVS uses the RCS branching mechanism. RCS makes very little claims as to the structure of your revision trees. CVS makes a few, like the fact that 3rd-party sources are on the 1.1.1 branch. [[ stuff deleted ]] All the stuff before the next quote is all reasonable and correct. > After having the initial versions established, I then wanted to define > another branch off of 1.1 (as 1.1.2), and label it as "SCO". > The following is what I did, and the results. > (3) Define a symbolic name for the initial version (V1_0). > (4) Define a branch for SCO specific changes to V1_0, or so I > thought. Now, we're getting into some of the magic that CVS uses in creating and manipulating RCS branches. I think you want to know more about the internal implementation of branching that CVS uses than I intended people to know. You have convinced yourself that you want a branch numbered 1.1.2 for your SCO hacks. CVS assumes that you want a branch for your SCO hacks, but doesn't make any guarantees as to its revision or branch number. If you trust CVS and allow it to choose your branch numbers, you will be pleased with the result. If you try to shoe-horn CVS's magic handling of branches into a "it must be 1.1.2 or else", then you will be unhappy (with CVS, that is). Now, let's go into some of the CVS branch magic... >----------------------------------- begin ----------------------------------- >$ cvs rtag -r1.1 V1_0 amby/tools # (3) >$ cvs rtag -b -r1.1 SCO amby/tools # (4) >------------------------------------ end ------------------------------------ This is the proper way to create a branch tag to support isolated, parallel development! Whew... I'm glad to see the man-page was clear on this. > I then checked out another version of the amby/tools module from the > repository, and examined a single file. >----------------------------------- begin ----------------------------------- >$ cvs checkout -rSCO -damby/tools/SCO amby/tools >U amby/tools/SCO/makefile > . > . >$ cvs status -v amby/tools/SCO/makefile >=================================================================== >File: makefile Status: Up-to-date > Version: 1.1 Fri Jun 5 14:52:40 1992 > RCS Version: 1.1 /scm/master/amby/tools/makefile,v > Sticky Tag: SCO (revision: 1.1) > Sticky Date: (none) > Sticky Options: (none) > Existing Tags: > SCO (revision: 1.1.0.2) > V1_0 (revision: 1.1) > releasetag_2 (revision: 1.1.1.1) > releasetag_1 (revision: 1.1.1.1) > vendortag (branch: 1.1.1) >------------------------------------ end ------------------------------------ > I am not sure why the "SCO" tag is revision 1.1.0.2, as I thought that > it should have been 1.1.2. Now, for the magic. As you can see from above, you created a branch called "SCO", then checked it out. The checked out revision you got was 1.1. As it turns out, CVS delays creating an actual new branch within your RCS file until you actually "commit" a permanent change on that branch. So, if you edit this newly checked out file using the "SCO" tag, then do "cvs commit" you will find that a branch is automagically created for you at that time. > How could I generate a 1.1.2 branch, and tag it? And, guess what? In this case, CVS will choose to create a branch called 1.1.2, just as you wanted! The sillyness you see with tag "SCO" being mapped to revision 1.1.0.2 is simply CVS's way of "reserving" the 1.1.2 branch for use by the SCO branch when a change is committed. The reason that CVS delays creating branches until the time of "commit" is: 1) I had thought that RCS stored the entire contents of the file within the leaf revision of each branch. I believe this assumption to now be incorrect. 2) Creating a branch revision can be done to existing, checked-out sources easily at any time with this design, since the revision numbers do not change as a result of creating a branch. 3) This design allows for much faster creation of branches than checking out the base version and checking it back in on the branch, which would be rather expensive. Creating a branch tag has very little "weight". 4) This design allows for a branch tag to be deleted just as a normal tag is deleted. If you had done commits, however, you may leave behind some physical branches in your RCS file. Oh well. 5) This design was pretty easy to code, using most of the tag code that already existed. So, now you know a bit about the internal stuff that CVS does with tags. This may answer some of the concerns that you had. -Brian