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.
The key features of PVCS are:
- It uses one storage file per source file.
- By default, the version timestamp is the time the source file was last modified. If the ".VCS_MODE : CheckinTime" directive is used, the version timestamp is the time the source file was checked in.
- The PVCS "get" program that checks out the source file sets the timestamp of the source file to the last modification time stored in the version.
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.
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!
The key features of SourceSafe are:
- Source files are archived in a project in a database. Opus Make can read these projects, using the "@" macro modifier.
- By default, the version timestamp is the time the source file was last modified. If the ".VCS_MODE : CheckinTime" directive is used the version timestamp is the time the source file was checked in.
- The SourceSafe "get" command that checks out the source file sets the timestamp of the on-disk source file to the current time only if the contents of the on-disk source file differs from the in-VCS source file.
- The SourceSafe database was changed between v3.x and v4.x and there are specific versions of Opus Make v6.1 for SourceSafe v3.x and v4.x.
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.
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.
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:
- It uses one storage file per source file.
- The version timestamp is the check-in time of the source file. There is no storage of the last-modified time.
- The RCS "co" program that checks out the source file sets the timestamp of the checked-out source file to the current time. Some versions of "co" can set the timestamp to the checked-in time.
MKS has released an enhanced RCS called Source Integrity that uses the same RCS storage files and adds:
- Source files can be organized into a project. A project can be worked on by multiple programmers, each in their own sandbox. Make can read the list of files from project and sandbox files with the "@" macro modifier. Make can also read timestamps from inside the storage files but you don’t really need this capability if you’ve already populated your sandbox with source files.
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.
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 value of SI macro $(projectdir) is "." if $(PROJECT) names a project file. Otherwise, if $(PROJECT) names a sandbox file the value of $(projectdir) is the directory of the project file referenced by the sandbox file.
- The value of SI macros $(drive_directory) are DRIVE:/directory unless you define your own drive_directory macro. For example, $(e_src) resolves to E:/src unless you define your own e_src macro.
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.
The key features of Burton Systems Software TLIB are:
- It uses one storage file per source file.
- The version timestamp is the time the source was last modified.
- The TLIB "EBS" command that checks out the source file sets the timestamp of the source file to the current time if "OldDate N" is configured in TLIB, or to the last modification time if "OldDate Y" is configured in TLIB.
- Versioned files can be organized into project-level tracking files, which Opus Make can read using the "@" macro modifier.
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.
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!