Definitions

Checkin

An operation that registers the changes that have taken place to an source file. Checking in the file removes any locks, and adds another node* to the version tree*.

Checkout

An operation that occurs when a file in the source archive must be modified. Checking out a file in most Version Control Systems* locks* it, and prevents other people from checking the file out. In most Version Control Systems* , a file cannot be examined unless checked out. In these types of systems, a special read-only checkout is done. This type of checkout allows other users to checkout the file and modify it.

Keywords

Special words that are automatically expanded upon checkout in many Version Control Systems* . For example, in SCCS* keywords are single letters surrounded by percent (%) signs. The special string %W% gets expanded into the file name, the date, and the SCCS version number. Once expanded, SCCS* keywords loose their meaning. Thus, SCCS* only expands it's keywords when a read-only checkout* is done. Under RCS*, keywords are whole words surrounded by dollar signs ($) For example, the string $Author$ gets expanded with the name of the user who edited the file like this: $Author: John Smith $. The keyword still remains when expanded, so RCS*expands it's keywords upon checkin*.

ClearCase does not have built in keyeword expansion since work on the source file is done directly in the ClearCase directory, and therefore, any information that keyword expansion would handle can usually be found via the cleartool describe command. However, many sites have emulated RCS*keyword expansion via a checkin trigger*.

Lock

A lock is something that will prevent changes from taking place in the Version Control Systems* system. In all Version Control Systems*, a lock can be placed upon a checked out file to prevent more than one person changing it at a time. In ClearCase, the concept of the lock is extended to include almost anything in the Source Archive including non-source objects such as version labels, etc.

Node

A particular version of the source file*. The name comes from the idea of a Version Tree* with a node of the tree representing a particular version of the file.

RCS

A Version Control System created by Dr. Walter F. Tichy in the early 1980's. RCS is very similar in implementation to SCCS* , but has improved many portions of the interface. For example, Keywords* are expanded somewhat differently, suffixes are used for the archive file instead of the s.* prefix which simplifies the issue of Makefile rules.

Sandbox

A Sandbox is a private area outside of the main development tree where developers can develop their code without affecting other users or the development tree. The many people claim that the term sandbox was named because this was the area where developers could play, and like sand castles, nothing was permement. However, as someone who has witnessed how some developers code, and as a cat owner, I have my own theories why the term sandbox became popular.

SCCS

The granddaddy of Version Control Systems* for Unix. Developed by AT&T back in the 1970s, SCCS soon became part of the standard Unix release. Now no longer under any further development, SCCS is part of the public domain. Although most people consider SCCS's syntax awkward and it's feature sets sparse, it is still a widely popular system to use. Because it is in the public domain, many commercial Source Configuration Management packages use SCCS as their basic versioning system

Many of the basic features that SCCS first used, and much of its operating principles have been copied by other Version Control Systems*. For example: the concept of checking in and out file from an archive. The use of Keywords* embedded in the source code that get expanded when the file is checked out. The use of locks to prevent two people from editing the same file, and the use of branches for parallel development.

Source File

Any file stored in the Version Control Systems* archive. Originally, SCCS could only handle text files (or program source files) and not binary files (or the compiled executables). Since all files stored in SCCS were originally source files, the term has been expanded to any file stored in the Version Control Systems*

Version Tree

Another name for the archive file that contains the source file. Comes from the idea that the various versions of the source file stored in the source archive may be represented by a tree diagram.

trigger

An action that automatically takes place due to another action. In ClearCase, many of the commands can have both preoperation and postoperation triggers.

View

A ClearCase term. A view is a method of looking at the development archive. Unlike other methods, a view makes the archive appear as a standard computer directory. With a view you specify what versions of all the files you would like to see, set the view, and work with the files directly in the archive.

Version Control System

Software that is used to keep track of the various versions of particular files. In a version control system, any version of a file can be called up. All Source Configuration Management Systems also contain a Version Control component.