Version Control Support

Intersolv PVCS   MKS & GNU RCS   Microsoft SourceSafe   Burton TLIB

The general form for version control support is:

.XXX_STORAGE : [ storage ] (source_file [ version ]) ... 

Where XXX is one of "PVCS", "RCS", "SS" or "TLIB", source_file is an extension or file name, storage is the VCS storage file name, and version is a version string.

Intersolv PVCS [Top]

Introduction to Intersolv PVCS

The key features of PVCS are:

Adding Version Control Support

The .PVCS_STORAGE directive tells Make about files or file extensions that can be in PVCS storage. This directive enables Make to look inside PVCS storage files to find version timestamps. Here are several examples:

.PVCS_STORAGE : .c .h .mak %    (1)
.PVCS_STORAGE : (.c –r 1.1) (.h –r 1.0.1)    (2)
.PVCS_STORAGE : .c_v(.c –r 1.1) .h_v(.h –r 1.0.1)    (2a)
.PVCS_STORAGE : main.c_v(main.c –r "Rel_1")    (3)
.PVCS_STORAGE : VCS/%.c(%.c -r "Rel_1")    (4)

Line (1) adds PVCS support for source files with extensions .c, .h and .mak, and for source files without an extension. Make computes that storage files have extensions .c_v, .h_v, .mav and .__v, respectively. When Make looks in these storage files it looks for the most recent main trunk version since no version was specified in the directive.

Line (2) modifies support for .c files by telling Make to look for version 1.1, and for .hfiles by telling Make to look for version 1.0.1. For PVCS users, note that 1.0.1 is a branch number and Make looks along this branch to find the most recent version. Line (2a) is the same as line (2), except we have told Make about the storage file extensions.

Line (3) modifies support for file main.c by telling Make to look for the version label Rel_1. All other .c files use version 1.1, as specified in line (2).

Line (4) shows PVCS support without mangling the storage file extension. The source- and storage-files have the same name, but the storage file is in the VCS subdirectory.

The Storage-Naming Scheme

There is a one-to-one mapping between source files and storage files, with the storage extension derivable from the source extension. The Opus Make PVCSSUFFIX macro controls this derivation. It is used like the PVCS LOGSUFFIX or ArchiveSuffix directive and has the same format: three mask characters followed by three default characters. To generate the PVCS storage extension, the source extension is padded out to 3 characters with the default, then mask characters other than "?" are substituted.

The default value of PVCSSUFFIX is "??v_ _ _". With this value some example mappings are: ".c" to ".c_v", ".for" to ".fov" and "." to "._ _v".

Important Note: If the PVCSSUFFIX macro is redefined the redefinition must occur before any .PVCS_STORAGE directives!

Microsoft SourceSafe [Top]

Introduction to SourceSafe and Visual SourceSafe

The key features of SourceSafe are:

Adding Version Control Support

The .SS_STORAGE directive defines files or extensions that are in SourceSafe storage. When a version string is specified in .SS_STORAGE it can be either –Vxx (xx a number) to specify a file version number or –VLyy (yy a string) to specify a project version label. Double quotes are needed if yy contains spaces (e.g. "–VLBeta 2"). If no version is specified, the most recent version is assumed. In terms of performance, Make processes project versions and the most recent version much faster than file versions.

The SSPROJECT macro names the default project (and optionally the default project version label) when a project isn’t specified in .SS_STORAGE. The SSPROJECT macro should be set in each makefile.

The SSDATA macro names the location of the SourceSafe "data" directory and should be set once, in make.ini. Here are example values of these two macros:

SSDATA = e:\ss\data    set in make.ini
SSPROJECT = $$/Make    (a) Specify the project
SSPROJECT = $$/Make "-VLBeta 2"    (b) Specify project & version

The following examples illustrate the use of the .SS_STORAGE directive:

.SS_STORAGE : .c .h .asm %    (1)
.SS_STORAGE : (main.c –V10)    (2)
.SS_STORAGE : (.asm "–VLRelease 1")    (3)
.SS_STORAGE : $$/AltProject(.pas "–VLBeta 3")    (4a)
.SS_STORAGE : $$/AltProject/%.pas(%.pas "–VLBeta 3")    (4b)

Line (1) adds SourceSafe support for .c, .h, .asm and extensionless files stored in the $/Make project. If the (a) SSPROJECT macro definition was used, the most recent versions of the source files will be used. If the (b) macro definition was used, the versions corresponding to project version label "Beta 2" will be used.

Line (2) modifies the support by indicating file version 10 for main.c.

Line (3) changes support for .asm files by specifying project version "Release 1".

Line (4a) specifies an explicit SourceSafe project name and project version "Beta 3".

Line (4b) has the same effect as (4a), but the use of the rule character gives .SS_STORAGE an inference-rule-like appearance.

Accessing Project Files

Make can access the list of files and subprojects that make up a project. The expression $(SSPROJECT,@) returns the file and subproject list for the project named by the SSPROJECT macro. The "@F" macro modifier returns the project files only. The "@P" macro modifier returns the project subprojects only. Appending "R" to the macro modifier causes recursion down through all the subprojects.

MKS & GNU RCS [Top]

Introduction to RCS

The Revision Control System (RCS) is a program that originated on UNIX systems and has been brought to other platforms by Mortice Kern Systems (MKS) and by the Free Software Foundation (GNU RCS). The key features of RCS are:

MKS has released an enhanced RCS called Source Integrity that uses the same RCS storage files and adds:

Adding Timestamp Reading

The .RCS_STORAGE directive tells Make about files or file extensions that can be in Source Integrity or RCS storage and that can be read for timestamps. As examples:

.RCS_STORAGE : .c .h .asm    (1)
.RCS_STORAGE : (.c –r1.1)    (2)
.RCS_STORAGE : h/RCS(.h –r"Rel 1.0")    (3a)
.RCS_STORAGE : h/RCS/%.h(%.h –r"Rel 1.0")    (3b)
.RCS_STORAGE : (.cpp -Psandbox.pj)    (4)
.RCS_STORAGE : make/RCS/%.cpp(%.cpp -Psandbox.pj)    (5)

Line (1) adds Make RCS support for source files with extensions .c, .h and .asm. When Make looks in the storage files in the RCS subdirectory it looks for the most-recent main trunk version since no version was specified in the directive.

Line (2) causes .c files to use version 1.1 instead of the most-recent version.

Line (3a) adds support for .h files to use the version labeled "Rel 1.0" in storage files in the h/RCS subdirectory. Because of line (1) Make also uses the most-recent version in storage files in the RCS subdirectory. Line (3b) is a pattern-based equivalent to (3a).

Line (4) adds support for .cpp files, with the version coming from the Source Integrity sandbox file sandbox.pj. The sandbox file references a project file and the project_ file_directory/RCS is the assumed location of the storage files.

Line (5) adds support for .cpp files in a pattern-based way. The storage files are named explicitly and the version comes from the Source Integrity sandbox.pj file.

Accessing Source Integrity Project Files

The expression $(PROJECT,@) returns the file list of the project or sandbox file named by the PROJECT macro. This list references SI macros, resolved by the following:

The Storage-Naming Scheme

There is a one-to-one correspondence between source and storage files, with the storage file name created by appending the value of the RCSEXT macro to the source file name. RCSEXT is predefined to ",v" for UNIX Opus Make and to "" for other platforms. You can define RCSEXT at any time, in make.ini or in the makefile.

Burton TLIB [Top]

Introduction to Burton TLIB

The key features of Burton Systems Software TLIB are:

Adding Version Control Support

The .TLIB_STORAGE directive tells Make about files or file extensions that can be in TLIB storage. Here are several examples:

TLIBEXT = ??x  
.TLIB_STORAGE : .c .h .asm %    (1)
.TLIB_STORAGE : (.c *)    (2)
.TLIB_STORAGE : (.c *–1)    (3)
.TLIB_STORAGE : (.h 1.1)    (4)
.TLIB_STORAGE : (.asm @file)    (5)
.TLIB_STORAGE : VCS/%.c(%.c *-1)    (6)

Line (1) adds Make VCS support for .c, .h, .asm and extension-less source files. Make uses the value of the TLIBEXT macro (see next section) to infer that the storage files have extensions .c_x, .h_x, .asx and .__x respectively. When Make looks in these storage files it looks for the most recent main trunk version since no version was specified in the directive.

Line (2) is an equivalent way to tell Make to look at the most recent version for storage files of .c files.

Line (3) tells Make to look at the next-to-most recent version for storage files of .c files.

Line (4) modifies support for .h files by telling Make to look for version 1.1.

Line (5) modifies support for .asm files by telling Make to use the TLIB snapshot file or project-level tracking file for determining the version.

Line (6) shows how to set up TLIB support without mangling of the storage file extension. Here the source file and storage file have the same names, except the storage file is in the VCS subdirectory. As in line (3), the "*-1" references the next-to-most-recent version.

The Storage-Naming Scheme

There is a one-to-one correspondence between source files and TLIB storage files, with the extension of the TLIB storage file derived from the extension of the source file. The Opus Make TLIBEXT macro controls this derivation. It is used exactly like the TLIB LibExt configuration parameter and has the same format: up to three characters that are either "?" (the mask character) or any other character. For each position in the TLIB storage file extension a TLIBEXT character of "?" selects the source file extension character unless there is none, in which case "_" is used. A TLIBEXT character other than "?" selects that character.

The default value of TLIBEXT, and the value we recommend for the TLIB LibExt configuration parameter, is "??x". With this value some example mappings are: ".c" to ".c_x", ".for" to ".fox" and "." to ".__x".

Important Note: If the TLIBEXT macro is redefined the redefinition must occur before any .TLIB_STORAGE directives!