[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

scm module in CVS (was Reports generation in CVS)

From: Frederic Brehm
Subject: scm module in CVS (was Reports generation in CVS)
Date: Thu, 03 Jun 2004 09:38:13 -0400

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.


Frederic W. Brehm, Sarnoff Corporation,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]