scm module in CVS (was Reports generation in CVS)

[Frederic Brehm]

At 10:04 AM 6/2/2004, Jim.Hyslop wrote:
> Fred, this sounds very useful. Would you be able to provide a more detailed
> description of this scm module, and perhaps the scripts as well?

I use the "scm" module (it goes by different names in different projects) 
to encode the project specific software configuration for the project. The 
scripts are not general enough to share, and I couldn't share them without 
going through too many layers of approval. But, I can tell you what they do.

First, some background. Sarnoff is a contract research organization 
involved in lots of technologies besides software. We used to be RCA 
Laboratories back in the day. We have a wide variety of clients with a lot 
of different requirements on the use of information. We have to guard 
customer information so it does not get transmitted to others. We also have 
to guard our own IP -- software, materials, designs, hardware, algorithms, 
etc. -- so its ownership is clearly ours. We use repositories on different 
servers (some belonging to us, some belonging to the client) to isolate 
ownership of software.

A project for a client usually involves combining our IP in ways that fit 
their requirements. BTW, the reason they hire us is for our unique IP, not 
our high price. Also, there is no single "library" or other product (I wish 
there were) we can produce from our software IP that would fit all of the 
client needs. That usually means developers need modules from different 
repositories in their sandbox.

So, one script is the "makesandbox" script that creates a sandbox using 
modules from multiple repositories. All of the other scripts depend on the 
structure of this tree. The makesandbox script often also checks for the 
presence of various third-party modules required by the project.

Another script, "build" builds the software product (or products in some 
cases) in the current sandbox. It could be just a call to "make", but it's 
usually more complicated than that (damn Windows).

The script "tag" tags all the files in the current sandbox. The script may 
impose a particular syntax on the tag. A comment is usually a required 
argument to this script. Various information about the operation is saved 
in a file and committed to the repository. The "scm" module is also tagged.

Finally, "release" takes a tag as an argument (and usually a required comment),
        1. saves information similar to the "tag" script,
        2. cd's to a directory devoted to creating releases,
        3. checks out the "scm" module into a directory with the name of 
the tag,
        4. runs makesandbox with the tag,
        5. sets up the proper environment, and then
        6. runs build.
All output from the script is redirected to a log file at the top level of 
the sandbox. This guarantees that a final build is produced from a clean 
development tree, and that we can easily archive the build environment. The 
result of this build goes through QA (we don't call it that, but that's 
what it is) and may be combined with other products before being shipped to 
the client.

If the software is shipped wrapped in some kind of installer, then the 
creation of the installer is usually in a separate script. This is because 
commercial installer packages are often licensed to a single person and we 
don't need to have every developer use the package.

Different projects have different wrinkles on these scripts. For example, a 
project may require both some firmware (compiled on Solaris) and a GUI 
(compiled on Windows). In that case, there is more than one "build" and 
"release" script.

Some steps may not be easily automated. The "scm" module always has .txt 
files describing the process required to perform standard actions.

I've considered using SCM packages like ClearCase, but the orientation of 
those packages is to set up a single management policy that is used over a 
long period of time or over a wide variety of products. The requirements in 
our environment change so much between clients that CVS+scripts seems a 
less costly approach.

Fred


_______________________________________________________________
Frederic W. Brehm, Sarnoff Corporation, http://www.sarnoff.com/