Each development shop has its own approach to defining, administering, and producing customer releases. ClearCase does not force you to adopt one approach over all others. In this tutorial, we explain the facilities that make certain approaches particularly natural and easy.
Having progressed this far in the tutorial, you have been exposed to the ClearCase method of defining the source base for a release. At the beginning of the tutorial, we spoke of the “first release” and the “second release” of the hello program. We soon switched, however, to describing these as the “REL1 release” and the “REL2 release”. That is, we switched to considering a release to be a particular set of source versions—those versions that have been labeled with a particular version label.
Thus, the “REL2 release” is defined by the versions of elements hello.c, hello.h, util.c, and Makefile that are labeled REL2. And we are about to define a third release by attaching the label REL3 to a set of source versions.
It may occur to you that this method of defining a release is circular. How do you keep track of all the particular versions, so that you can attach a label to them? You'll see that ClearCase has good facilities in this regard, both for simple situations (like the one in this tutorial) and for complex ones, involving many programs and development trees.
At the end of the preceding lesson, you were in the src directory, in a shell set to view USER_HOST_tut. Verify that you are still in the same situation.
% cleartool pwv -short USER_HOST_tut % pwd VOBTAG/src |
If you've gotten lost, you may need to use a full pathname to find the source directory.
cd VOBTAG/src |
If this command fails, it is probably because you exited the shell that was set to your view. Enter the following commands to reestablish your view context and your working directory within the VOB.
cleartool setview USER_HOST_tut cd VOBTAG/src |
Defining version labels works in much the same way as defining names for branches of version trees (Step 52). There are two steps:
Create a version label type, using the mklbtype (“make version label type”) command. This is an administrative object that defines a particular version label for subsequent use in this VOB.
Attach the version label to one or more element versions, using the mklabel (“make version label”) command.
% cleartool mklbtype REL3 Comments for "REL3": Release 3 version label . Created label type "REL3". |
Having defined version label REL3 for use within this VOB, you can now attach it to elements.
This is a very simple product release. It consists of a single executable program, hello, whose source tree consists of a single directory (the one you are in), VOBTAG/src. You have just built the instance of hello that will be shipped, so your view's versions of the sources are the ones that should get the REL3 label.
% cleartool mklabel REL3 Makefile hello.c hello.h util.c . .. Created label "REL3" on "Makefile" version "/main/2". Created label "REL3" on "hello.c" version "/main/3". Created label "REL3" on "hello.h" version "/main/1". Created label "REL3" on "util.c" version "/main/3". Created label "REL3" on "." version "/main/2". Created label "REL3" on ".." version "/main/1". |
As discussed in the introduction to Lesson 5, the “.” and “..” arguments include the current working directory and the parent directory in the list of elements whose current version is to be labeled. In general, version labels should be applied to the entire chain of directories between the current directory and the VOB mount point. In this example, the parent directory is the VOB mount point.
Since every source file and directory is now labeled REL3, anyone can reconstruct the source base for this release with a single config spec rule: element * REL3.
That was easy, but not particularly realistic. In real life, an individual developer often is not the person who decides when a program is good enough to release. It is more likely that a QA manager or development manager will make such decisions, having tested a particular build of the program.
ClearCase supports this kind of release policy easily. After some build of the hello program is finally approved for release by the powers-that-be, the config rec of that build can drive the assignment of version labels to sources. Exercise this feature now, using an alternative form of the mklabel command. The output shows that the work of the preceding step is repeated.
% cleartool mklabel -replace -config hello REL3 Label "REL3" already on "VOBTAG" version "/main/1". Label "REL3" already on "VOBTAG/src" version "/main/2". Label "REL3" already on "VOBTAG/src/hello.c" version "/main/3". Label "REL3" already on "VOBTAG/src/hello.h" version "/main/1". Label "REL3" already on "VOBTAG/src/util.c" version "/main/3". |
Note that this version of the command did not attempt to label the Makefile. This is because the config rec does not list a version of the Makefile. Instead, the config rec includes the text of the build script that was executed.
This strategy allows a Makefile to support many targets independently. A Makefile-level change requires a rebuild only of the target whose build script or dependencies are modified—all other targets are still “up-to-date”. (If the config rec listed a version of the Makefile, the entire Makefile would be a dependency of each of its targets. Each time the Makefile changed, every target would be rendered “out-of-date”.)
You have taken care of the sources. Now for the executable in the bin directory.
% cleartool checkout -nc ../bin/hello Checked out "../bin/hello" from version "/main/2". % cleartool checkin -from ./hello -rm ../bin/hello Checkin comments for "../bin/hello": Release 3 version . Checked in "../bin/hello" version "/main/3". |
Your new executable is checked in. (The -rm option deletes the checked-out copy of ../bin/hello, suppressing the Save private copy? prompt that otherwise appears when you check in a version from an alternate location with -from.)
Now let's apply the REL3 label the release directory (../bin) and its contents (../bin/hello).
% cleartool mklabel REL3 ../bin ../bin/hello Created label "REL3" on "../bin" version "/main/1". Created label "REL3" on "../bin/hello" version "/main/3". |
Note that, like Step 78, this step attaches a version label to the currently-selected version of a directory—this time, it is ../bin. (There is no need to “walk up the tree” to the VOB mount point—the parent directory of ../bin is the VOB mount point, which has already been labeled.)