home *** CD-ROM | disk | FTP | other *** search
Text File | 1992-07-31 | 60.7 KB | 1,356 lines |
-
-
-
-
-
-
-
-
-
- ======================================================
-
-
-
-
- Project Source Code Manager
-
- Version 1.3
-
- July 31, 1992
-
-
-
-
- ---------------------------
-
-
-
-
- Copyright (c) 1990-1992
-
- J. Bart Henthorn
-
- All Rights Reserved
-
-
-
-
- ======================================================
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- The programs described in this documentation are the copyrighted
- works of J. Bart Henthorn. They are expressly distributed under
- the ShareWare concept. They are not free. You must license them
- if you use them beyond the initial trial period.
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Introduction to PSCM.............................................1
-
- Installing PSCM..................................................2
-
- The PSCM Configuration File......................................2
-
- The Project Source Files.........................................3
-
- The Project Database File........................................3
-
- The Item File System.............................................4
-
- The CHECKIN Program..............................................5
- Adding New Files to a Project Database......................5
- Updating Files in the Project Database......................5
- Adding Comments to the Project Database File................6
- Entering Comments...........................................6
- Saving a Set of Files in the Database.......................7
- Viewing Differences in the Source Files.....................8
- Undoing A Previous CHECKIN..................................8
-
- Special Macros in Source Files...................................10
- The Revision Comments Macro.................................11
-
- The CHECKOUT Program.............................................12
- Retrieving for Editing or Making............................12
- Listing the Files in the Project Database...................13
- Listing Comments in the Project Database....................13
- Listing or Retrieving File Sets.............................14
-
- Using PSCM with Make Programs....................................15
- Step 1: Pre- and Post-Processing...........................15
- Step 2: Templates..........................................16
- Enhancements................................................16
-
- PSCM is ShareWare................................................18
-
- Revision History.................................................19
- Bugs Fixed and Enhancements Added to Version 1.3............20
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Table of Contents PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- PSCM - Project Source Code Manager
- PSCM - Project Source Code Manager
- __________________________________
- __________________________________
-
- PSCM consists of two main programs: CHECKIN and CHECKOUT. These
- two programs control a project database that contains the
- complete source code and support files for a project. The basic
- function of PSCM is to maintain and archive various versions of
- the project source code as it evolves. At any point in time it
- should be possible to retrieve the full set of files needed to
- create the project at any point in time.
-
- PSCM manages the different revisions by assigning a Version
- Number to each different version of the files. This number has
- three parts as follows:
-
- M.N.R where:
-
- M The major version number. This number may range from 0
- to 32767.
- N The minor version number. This number may range from 0
- to 32767.
- R The revision number. This number may range from 0 to
- 32767 and is used to indicate intermediate revisions
- between releases.
-
- When a project's files are identified by only the major and minor
- version numbers, this is referred to as a "Version." When the
- revision number is included, this is called an "Instance." When
- a set of files is retrieved for a particular Version, the most
- recent Instance of all files is retrieved. It is also possible
- to retrieve a specific revision of a file.
-
- The database maintains an internal directory of files that
- constitute a project set. This directory contains a list of all
- source code files as well as any comments or set descriptions
- that have been entered. Once an item has been added to a project
- database it is not possible to remove it (with one exception
- described later). It is for this reason that you should be sure
- about your actions when you add an item to a database.
-
- PSCM stores only the latest instance of a file in the database.
- Prior instances are stored as "Difference Scripts." These
- scripts are generated and used by the three PSCM support
- programs: DIFS, MRGS, and SHOWDIFS. DIFS compares two files and
- produces a script file that describes how they differ. MRGS uses
- a script file and the later version source file to produce the
- earlier version source file. SHOWDIFS uses a script file and the
- later version source file to display the differences between the
- later and earlier versions.
-
- PSCM also allows the inclusion of comments in the database file.
- When one or more files have been changed, and new Instances of
- the files are added to the database, an optional comment may be
- saved. Along with the comment is a list of the files modified
- and their revision level and file date and time. These comments
-
- PSCM v1.3 page 1
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- may be either listed one at a time or all comments at once. The
- same comment is entered for all files updated during that run.
- This saves you from having to reenter the same information over
- and over again. It is also possible to feed the comment from an
- ASCII file by using the redirection features of DOS.
-
- During development it may be desirable to take a "Snapshot" of
- the current revision level of all files in the database. PSCM
- allows this function through the use of "Sets." When a Set is
- created a record is made of all source files at their most recent
- Instance. This is stored along with a comment which can be used
- to describe the Set. At any point in time it is possible to
- recreate the exact state of these files using the CHECKOUT
- program's Set command. It is also possible to generate a list of
- all Sets in the database.
-
- PSCM also supports a limited "Undo" function. Since we humans do
- occasionally make mistakes, PSCM saves information about the
- items changed during an update. This information is only one
- level deep; you can only undo the most recent update to the
- project database. The undo is a one-way undo. This means that
- you cannot undo an undone database. Once you undo a database the
- necessary information is removed.
-
- Installing PSCM
- Installing PSCM
- _______________
- _______________
-
- PSCM version 1.3 contains six program files (CHECKIN.EXE,
- CHECKOUT.EXE, DIFS.EXE, MRGS.EXE, SHOWDIFS.EXE, and ISIZE.EXE).
- These files should be placed in a directory along your PATH.
- This will make them accessible from anywhere on your system.
- There is also a standard configuration file named PSCM.CFG. This
- file is a normal ASCII text file (see description below). You
- should edit this file to suit your system and then put it in the
- same directory with the CHECKOUT.EXE program file.
-
- The PSCM Configuration File
- The PSCM Configuration File
- ___________________________
- ___________________________
-
- PSCM uses a configuration file to store some basic information
- used when expanding some of the special macro strings described
- later. The configuration file is an eight line text file. The
- first line in the file is called the "System" line. The text of
- the first line is used when expanding the System Name macro. The
- remaining seven lines are called "User Parameters." They are
- used when expanding the seven User macros. Each of the lines in
- the configuration file is limited to a maximum of 63 characters.
- PSCM will truncate an entry at the 63rd character when using it
- to expand a macro.
-
- When the CHECKOUT program begins execution, it attempts to open
- the configuration file "PSCM.CFG" in the current directory. If
- it cannot find the file in the current directory, and you are
- using DOS version 3.0 or later, it will attempt to load the
- configuration file from the directory where the CHECKOUT program
- was loaded. This allows you to have a default configuration
-
- page 2 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- stored in the same directory as the CHECKOUT.EXE file and to have
- a project specific configuration in the working directory.
-
- For example, suppose you keep a stock configuration file in the
- directory where you keep your program files. This file has User
- Parameter #1 set to your standard copyright message. If you
- wanted to change the copyright message for a special project you
- could simply copy the stock PSCM.CFG file to the same directory
- with your source files and then edit User Parameter #1.
-
- The Project Source Files
- The Project Source Files
- ________________________
- ________________________
-
- A Project's source files are plain ASCII text files that contain
- the source code for a project. The source files may also include
- the various support files used to create and maintain the project
- such as a make file and batch files. For example, the PSCM
- project has several 'C' code source files, a couple of 'C' header
- files, a make file and a few batch files. Taken together, these
- files are all that is necessary to recreate the entire project
- from scratch.
-
- -----------------------------------------------------------------
- NOTE PSCM can only work with plain ASCII text files. It
- NOTE
- will not handle word processor files properly. The
- various control codes in most word processor files will
- corrupt the PSCM database file.
- -----------------------------------------------------------------
-
- The Project Database File
- The Project Database File
- _________________________
- _________________________
-
- The Project Database file is used to hold all information about
- the project's source files. There is no requirement on the name
- of the file, however the convention is to name it the same as the
- project with no extension. For example, my project file for PSCM
- is named "PSCM". The project database file need not even be in
- the same directory as the rest of the project files. This allows
- you to place the project file on another drive or in another
- directory for that added "Peace of Mind."
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PSCM v1.3 page 3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- The Item File System (IFS)
- The Item File System (IFS)
- __________________________
- __________________________
-
- PSCM project files use a database manager called the "Item File
- System." This DBMS allows records in the database to be of
- varying lengths. It is also very fast because it uses a hashing
- algorithm to store the records. When a project file is first
- created (by the CHECKIN program) it is given a default size
- (called a "Modulo") of 47. As the project database file grows it
- may be necessary to resize the file to improve retrieval speed.
- The ISIZE program is used to resize the project database file.
- Use the following command:
-
- ISIZE -r PROJECT
-
- The ISIZE program will inspect the project database file and then
- create a new file with a new size and copy all items from the old
- file to the new file. It will then delete the old file and
- rename the new file to the old file name.
-
- -----------------------------------------------------------------
- NOTE The old file will only be deleted if the new file is
- NOTE
- created correctly. If the ISIZE program encounters any
- errors the old file will be left intact.
- -----------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- page 4 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- The CHECKIN Program
- The CHECKIN Program
- ___________________
- ___________________
-
- The CHECKIN program is used to add project files to the database
- and to create new Versions or Instances of files. CHECKIN is
- also used to add comments to the database, to create project
- Sets, and to undo a previous CHECKIN command.
-
- -----------------------------------------------------------------
- NOTE None of the CHECKIN command forms discussed will alter
- NOTE
- the source files. They are left on disk exactly as
- before CHECKIN was run.
- -----------------------------------------------------------------
-
- Adding New Files to a Project Database
- Adding New Files to a Project Database
-
- When adding one or more new files to the project database, or
- when creating a new Version level, the Version numbers must be
- specified via a command line switch as follows:
-
- CHECKIN -vM.N PROJECT FILE1 FILE2 ... FILEn
-
- The '-v' switch is used to specify the major and minor version
- numbers. As with most CHECKIN commands you can use wildcards to
- specify the files. However, you cannot specify files that are
- not in the current directory; all files specified must be in the
- current directory.
-
- Note that the revision number is not specified, it is set to 0 by
- the program. If a copy of the file already exists at the
- specified Version level, a warning message will be displayed and
- the file will be skipped. This feature is particularly handy
- when adding new files to an existing project database.
-
- For example, assume you have created three new source files, two
- with the extension ".C" and one with the extension ".H". You can
- easily add these to the project database by using wildcards to
- specify all .C and .H files (e.g. "*.C *.H"). Only the new files
- will be added to the database; any files already existing in the
- project database will be skipped.
-
- Updating Files in the Project Database
- Updating Files in the Project Database
-
- To create a new Instance of an existing file, the following
- command line is used:
-
- CHECKIN -i PROJECT FILE1 FILE2 ... FILEn
- -or-
- CHECKIN -i PROJECT
- -or-
- CHECKIN -iM.N PROJECT FILE1 FILE2 ... FILEn
- -or-
- CHECKIN -iM.N PROJECT
-
-
-
- PSCM v1.3 page 5
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- When no file names are specified on the CHECKIN command line, all
- source files that have been modified since they were last checked
- in are updated. This is a shorthand way of updating all modified
- files. You can also use wildcards to specify the files that will
- be updated.
-
- The first command form is used to create new Instances for the
- specified files at the most recent Version level. The second
- command is the same except that all modified files in the most
- recent Version are updated to a new Instance. These two forms
- are the most common used in project management.
-
- The third and fourth commands are similar to the first two except
- a specific Version level is updated instead of the most recent.
- These two command forms are used when a previous CHECKOUT was run
- to retrieve a Version other than the most recent.
-
- Adding Comments to the Project Database File
- Adding Comments to the Project Database File
-
- The '-i' switch discussed above is used to create new Instances
- of source files. But it is also possible to add a comment record
- at the same time. The following commands behave the same except
- that they also allow an optional comment record to be created and
- saved with the files. The comment record contains one or more
- lines of text and a list of the files updated. The following
- command forms are used to create comment records:
-
- CHECKIN -c PROJECT FILE1 FILE2 ... FILEn
- -or-
- CHECKIN -c PROJECT
- -or-
- CHECKIN -cM.N PROJECT FILE1 FILE2 ... FILEn
- -or-
- CHECKIN -cM.N PROJECT
-
- The same comment is saved with every file updated. This allows
- you to easily apply the same comments to every file modified
- since the last update. If you need to save a specific comment
- with a small subset of files you should run CHECKIN and specify
- those files that will receive the different comment. You can
- then use the second command form shown above to pick up the
- remaining files and give them a global comment.
-
- If you do not specify a comment (by entering Control+Z "^Z"
- without any text) then no comment will be saved with the files
- but they will still be updated in the project database. This
- allows you to always use the "-c" switch to update files and only
- enter comments when you truly need to comment on the update.
-
- Entering Comments
- Entering Comments
-
- CHECKIN reads comments, one line at a time, from STDIN. You can
- edit the current line only; once you press <Enter> at the end of
- the line you cannot edit that line any more. When you are done
-
- page 6 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- entering the comment, enter a Control+Z "^Z", either using the
- <Ctrl>+<Z> keys or by pressing the <F6> function key, and then
- press <Enter>. This ends the current comment. Note that there
- is no limit to the number of lines in a comment, but there is a
- limit to the width of a comment line. No comment line should
- extend past column 80, but you may find that output formatting is
- easier if you limit comment lines to something less than this.
-
- Because CHECKIN can read the comments from an ASCII file using
- redirection, you may find it easier to enter your comments into a
- text file and then redirect them into CHECKIN from the command
- line. For example, assume that you have saved all your comments
- in a text file called "COMMENTS". You can update the project
- database and save the contents of the COMMENTS file as the update
- comment using the following command:
-
- CHECKIN -c PROJECT < COMMENTS
-
- -----------------------------------------------------------------
- NOTE It is generally NOT a good idea to enter source file
- NOTE
- comment symbols in a revision comment. In some
- languages, most notably 'C', the comment symbols in the
- expanded comment macro could cause compilation errors.
- -----------------------------------------------------------------
-
- Saving a Set of Files in the Database
- Saving a Set of Files in the Database
-
- During the development process it may be useful to save a record
- of the current revision level of all files in the database. This
- record is called a "Set." It is commonly used as a place marker
- to indicate where specific versions of the project were generated
- and released. For example, if you are in the habit of releasing
- preliminary versions to a small group of testers, the Set
- function can be used to regenerate the source code used for each
- tester's version of the program. This allows you to forge ahead
- making fixes and enhancements to the project, yet still pull the
- "release" version to check on specific bug reports.
-
- The command used to generate a Set is:
-
- CHECKIN -s PROJECT
- -or-
- CHECKIN -sM.N PROJECT
-
- Note that no file names are specified on the command line. This
- is because the Set command generates and saves a list of all
- files in the database. The first command form will generate a
- set for the most recent Version, while the second form is used to
- create a set for a specified version.
-
- Note that you must also enter a "Set Comment." If you do not
- enter a comment (or enter a blank comment) then the set will not
- be created.
-
-
- PSCM v1.3 page 7
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Viewing Differences in the Source Files
- Viewing Differences in the Source Files
-
- After making changes in the source files, and before checking
- them into the project database, you can view the changes you have
- made. The "-d" command switch is used to compare the current
- versions of the source files on disk with the most recent
- Instances saved in the project database.
-
- CHECKIN -d[M.N] PROJ [FILE1 FILE2 ... FILEn]
-
- If you do not specify a version ("M.N" in the above command spec)
- then the most recent version will be used, otherwise the files
- from the specified version will be compared. If you do not
- specify any files then every file in the project database will be
- compared. If files are specified then only those files will be
- compared.
-
- This command compares the source files found on disk with the
- most recent Instances at the specified (or most recent) Version
- in the project database. It does not alter the project database
- _______________________________________
- file. The differences will be written to a file with the same
- ____
- base name as the source file but with the extension "__D". For
- example, assume you have modified the source file "FILE1.C" and
- then enter the following command:
-
- CHECKIN -d PROJ FILE1.C
-
- The differences between the on-disk version and the checked-in
- version will be written to a file named "FILE1.__D".
-
- The following is an example of the difference file format:
-
- < = Version on disk; > = Version checked in
-
- < DESC desc1;
- ----------------------------------------
- > DESC desc1, desc2;
-
- < run_showdifs(difscript, filename, difoutname);
- ----------------------------------------
- > run_showdifs(filename, difscript, difoutname);
-
- -----------------------------------------------------------------
- NOTE No check is made for source files that already have an
- NOTE
- extension of "__D". This situation could cause severe
- problems including the possible loss of the source file
- on disk.
- -----------------------------------------------------------------
-
- Undoing A Previous CHECKIN
- Undoing A Previous CHECKIN
-
- From time to time you may find it necessary to "undo" the most
- recent CHECKIN command on a project database. This usually
- happens because you have accidentally added the wrong files to a
-
- page 8 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- project file or because you entered a wrong comment. Whatever
- the reason it would be nice if you could "take that back." The
- CHECKIN program allows a limited form of this. The "-u" command
- switch will undo the changes made to a project database by the
- most recent CHECKIN run.
-
- When CHECKIN makes modifications to a project database it saves
- information in the database about what items were added and which
- items were changed and how they were changed. This information
- is used to restore the database to it original condition. To
- undo a previous CHECKIN run use the command:
-
- CHECKIN -u PROJ
-
- CHECKIN will first inspect the project database file (PROJ in the
- above example) and determine if the necessary information is
- present. If it is not possible to undo the database then CHECKIN
- will print an error message to this effect and exit. The undo
- information is deleted at the beginning of a modification run.
- This means that once you begin an update (using the "-v", "-i",
- "-c", or "-s" command switches) you can no longer undo the
- previous modification. This is true even if you abort the
- current run by pressing Control+C or Control+Break.
-
- If the necessary information is present in the database then
- CHECKIN will prompt you to verify that you truly wish to undo the
- modifications made by the previous CHECKIN. Press "Y" or "y" to
- continue with the undo process. Any other key will cause CHECKIN
- to abort the undo leaving the undo information intact.
-
- As each file is restored to its previous version a progress
- message will display indicating which file is being affected and
- what version is involved. Note that the Control+C and
- Control+Break keys are ignored during an undo process. When the
- undo is complete the undo information is deleted from the project
- database.
-
- -----------------------------------------------------------------
- NOTE Undo does not alter any source files on disk. It only
- NOTE ______________
- modifies the contents of the project database file.
- -----------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PSCM v1.3 page 9
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Special Macros in Source Files
- Special Macros in Source Files
- ______________________________
- ______________________________
-
- When files are retrieved for editing (see the description of the
- CHECKOUT program below), certain special "Macro" strings are left
- in the unexpanded form. When files are retrieved for making
- (i.e. compiling, assembling, etc.) these Macros are expanded.
- The Macros can be used to specify version numbers, file dates and
- times, file names, etc.
-
- The Macros are used to place information about the system,
- project, or file in the text of the file. When the file is
- retrieved for making, the Macros are replaced with the
- information specified. There are two types of date and time
- macros. One form is used to place the current SYSTEM date and
- time in the file. This is the system date and time when the file
- is retrieved. The other form is used to place the FILE's date
- and time in the text. This is the date and time of the last
- modification to the file.
-
- General Macros
- -------------------------------------------------------
- @#D System Date in the form mm/dd/yy
- @#T System Time in the form hh:mm:ss
- @#P Project name
- @#c Revision history comments
-
- Configuration File Macros
- -------------------------------------------------------
- @#S System name from the PSCM config file
- @#1 User parameter 1 from the PSCM config file
- @#2 User parameter 2 from the PSCM config file
- @#3 User parameter 3 from the PSCM config file
- @#4 User parameter 4 from the PSCM config file
- @#5 User parameter 5 from the PSCM config file
- @#6 User parameter 6 from the PSCM config file
- @#7 User parameter 7 from the PSCM config file
-
- Version and Revision Macros
- -------------------------------------------------------
- @#v Version number in the form M.N
- @#r Revision number in the form M.N.R
- @#M Major version number
- @#N Minor version number
- @#R Revision number
-
- Source File Modification Information Macros
- -------------------------------------------------------
- @#d File date in the form mm/dd/yy
- @#t File time in the form hh:mm:ss
- @#f File name and extension in the form filename.ext
- @#F File name part only (no extension)
-
-
-
-
- page 10 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- The Revision Comments Macro
- The Revision Comments Macro
-
- The '@#c' macro is slightly different than all the others. When
- it is processed, it puts the revision history comments for the
- source file in the text. The part of the line already printed is
- put at the beginning of each line before it is inserted in the
- text. For example, if the lines:
-
- /*
- * @#c */
-
- are in the source text, they will be expanded to look like:
-
- /*
- *
- * Revision M.N.R entered at HH:MM:SS on MM/DD/YY
- * Comment line 1
- *
- * Revision M.N.R entered at HH:MM:SS on MM/DD/YY
- * Comment line 1
- * Comment line 2
- *
- * */
-
- Only those comments entered when a file was updated and then
- checked in using the CHECKIN option '-c' will be printed. Even
- though the comment may have been entered when more than one file
- was updated, the comment text will be printed if the current file
- was included in the update.
-
- The comment text is placed in the text file starting with the
- most recent revision and proceeding to the oldest. When a file
- is extracted at a specific revision, only those comments which
- were entered before or at the revision are placed in the file.
- If no comments are found, the '@#c' macro is simply discarded.
-
- -----------------------------------------------------------------
- NOTE It is generally NOT a good idea to enter source file
- NOTE
- comment symbols in a revision comment. In some
- languages, most notably 'C', the comment symbols in the
- expanded comment macro could cause compilation errors.
- -----------------------------------------------------------------
-
-
-
-
-
-
-
-
-
-
-
-
-
- PSCM v1.3 page 11
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- The CHECKOUT Program
- The CHECKOUT Program
- ____________________
- ____________________
-
- The CHECKOUT program is used to retrieve files from the most
- recent or a specified Version level. The files can be retrieved
- for one of two purposes: Editing or Making.
-
- Retrieving for Editing or Making
- Retrieving for Editing or Making
-
- When files are retrieved for editing, all special Macros are left
- in their unexpanded form and the file is written to disk as a
- modifiable file. When files are retrieved for making, the
- special Macros are replaced by the appropriate information and
- the file is marked read-only. This prevents modification of the
- file.
-
- When a file is retrieved (either for editing or making) it is
- actually retrieved only if the file on disk is different than the
- retrieved version or the last version was retrieved for the
- opposite purpose. For example, if a file is retrieved for
- editing and the version on disk is different (i.e. has a
- different date and time stamp) then the file will be written to
- disk. If the file is the same but was last retrieved for editing
- and is now being retrieved for making, the file will be written
- to disk. Note that when a file is checked in (using the CHECKIN
- program) the file on disk is assumed to be retrieved for editing.
-
- -----------------------------------------------------------------
- NOTE This behavior can sometimes cause problems. Make sure
- NOTE
- that you really want CHECKOUT to overwrite ALL POSSIBLE
- files first. Because of the way DOS overwrites
- existing files it will not be possible to retrieve a
- new, and as yet not checked-in, version of a source
- file once CHECKOUT has overwritten it.
- -----------------------------------------------------------------
-
- The command line for CHECKOUT is as follows:
-
- CHECKOUT -e[M.N[.R]] PROJECT [FILE1 FILE2 ... FILEn]
- -or-
- CHECKOUT -m[M.N[.R]] PROJECT [FILE1 FILE2 ... FILEn]
-
- The '-e' switch is used to retrieve files for editing. The '-m'
- switch is used to retrieve files for making. Only one is allowed
- on the command line.
-
- When the Version level is omitted, the most recent version is
- retrieved. If the Revision number is omitted, the most recent
- Instance is retrieved. Note that you must specify a Version in
- order to specify a Revision.
-
- If you do not specify any file names on the command line, all
- files which are different than the version on disk will be
- retrieved. If one or more files are named in the command, only
- those files will be retrieved. Note that a file will be
-
- page 12 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- retrieved only if the version on disk is different (has a
- different time and date) or was last retrieved for the opposite
- purpose (editing versus making.)
-
- You can use wild cards to specify files for extracting. This
- allows you to easily specify that all files of a specific type be
- extracted in one command. You might use this in a MAKE control
- file to extract all inclusion files before actually beginning the
- compilation of the source files.
-
- Listing the Files in the Project Database
- Listing the Files in the Project Database
-
- The CHECKOUT program is also used to list files in a specific or
- the latest version. The listing shows each file's name, time and
- date, and full version and revision number. The command is as
- follows:
-
- CHECKOUT -l[M.N[.R]] PROJECT [FILE1 FILE2 ... FILEn]
-
- Note that the command switch is a lower case ell, not the digit
- one. As with the other forms of the CHECKOUT command, the
- version and revision numbers and the file names are optional.
-
- Listing Comments in the Project Database
- Listing Comments in the Project Database
-
- CHECKOUT can also list the comment records stored in the
- database. When new Instances of files are created using the '-c'
- switch in the CHECKIN program, a comment record is saved along
- with a list of the files that were updated. CHECKOUT can list
- either a specified comment record, all comment records, or only
- comments for a specific file or files. The commands used are as
- follows:
-
- CHECKOUT -c[M.N] PROJECT
- -or-
- CHECKOUT -cM.N.R PROJECT
- -or-
- CHECKOUT -c[M.N] PROJECT FILE1 FILE2 ... FILEn
- -or-
- CHECKOUT -cM.N.R PROJECT FILE1 FILE2 ... FILEn
-
- The first command form is used to list all comment records. If a
- Version is specified then all comments for that version will be
- listed. Otherwise all comments for the latest version are
- listed.
-
- The second command form is used to list a specific comment
- record. As with source files, all comment records are assigned a
- Revision number. This revision number is not related to the
- revision numbers of the other files in the database, it is simply
- used to track sequential comments.
-
- The third and fourth command forms are used to display the
- comments for specific source files. The former method lists all
-
- PSCM v1.3 page 13
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- comments entered when the specified files were updated. The
- latter form lists only those comments entered up to and including
- the Revision of the source file specified. Both forms list the
- comments one source file at a time. This means that a single
- comment may be repeated many times, once for each file listed.
-
- The output from the Comment command is sent to STDOUT. This
- means that it may be redirected to a file or piped to another
- program if desired.
-
- Listing or Retrieving File Sets
- Listing or Retrieving File Sets
-
- The CHECKOUT program is also used to list or retrieve Sets saved
- in the project database using the CHECKIN program. The Set
- command forms are as follows:
-
- CHECKOUT -s[M.N] PROJECT
- -or-
- CHECKOUT -sM.N.R PROJECT
- -or-
- CHECKOUT -rM.N.R PROJECT
-
- The first form is used to list all Sets saved in the project
- database file. If a Version is specified then only Sets for that
- version are listed. If the Version is omitted, then the Sets for
- the most recent Version are listed. The listing includes the
- comment saved when the Set was created along with a list of all
- files and their revisions that were saved in the Set. The
- listing is sent to STDOUT so it may be redirected to a file or
- piped to another program.
-
- To retrieve the files from a specific Set, the second and third
- command forms are used. An exact Version and Instance must be
- specified. Note that the Revision numbers of the Sets are not
- related to the Revision numbers for files. All files are
- retrieved at their extant Version and Instance when the Set was
- created.
-
- When the '-s' switch is used, the files are retrieved for Making,
- so all special macros are expanded and the files are marked as
- read-only to prevent modification. If the '-r' switch is used,
- then the files are retrieved for Editing. All macros are left
- unexpanded and the files are made modifiable. Once a Set has
- been retrieved, the files may be used to rebuild the project or
- simply viewed or printed as desired.
-
-
-
-
-
-
-
-
-
-
- page 14 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Using PSCM with Make Programs
- Using PSCM with Make Programs
- _____________________________
- _____________________________
-
- PSCM was designed expressly for use with the various MAKE
- programs and utilities available both through ShareWare and
- commercially. In fact, with a little thought you will find that
- PSCM ceases to be of any concern. You just MAKE your project the
- way you always do and PSCM handles the modifications without
- trouble.
-
- When files are retrieved from a project database (by the CHECKOUT
- program) they are given the proper time and date so MAKE can make
- the right decisions about what should be rebuilt. PSCM will only
- store or retrieve files that are different thus easing the
- control issues.
-
- Step 1: Pre- and Post-Processing
- Step 1: Pre- and Post-Processing
-
- There are just a few things that you need to do to integrate PSCM
- into your development environment. The first is to identify
- where the "PRE" and "POST" processing is done in your make
- process. Most MAKE programs have readily identifiable stages
- where PSCM can be added. For example, I use NDMAKE version 4.5
- (a very good MAKE utility if you can still find it). NDMAKE,
- just like Unix make, makes the first target found in the control
- file. Most control files wind up with a primary target that
- looks like the following:
-
- build: prog1.exe prog2.exe prog3.exe
-
- Since "build" is a dummy target (it never exists so must always
- be remade), NDMAKE proceeds down the list of dependents,
- rebuilding whatever is necessary to update them. The effect of
- this is to rebuild all of the program files in the project. This
- is an excellent candidate for inclusion of PSCM. We can add two
- new dummy targets to handle the pre- and post-processing needed
- by PSCM.
-
- The preprocessing stage consists of checking in any updated or
- modified files, and then checking out any files that are not
- direct targets (i.e. header and inclusion files). If we are
- using 'C' we might rewrite our make control file as follows:
-
- build: PREP prog1.exe prog2.exe prog3.exe FINI
-
- PREP:
- CHECKIN -C PROJ
- CHECKOUT -M PROJ *.H
-
- FINI:
- CHECKOUT -E PROJ
-
- The PREP dummy target will always cause the CHECKIN and CHECKOUT
- commands to execute. The CHECKIN command causes all modified
- files to be updated in the PROJ project database and prompts for
-
- PSCM v1.3 page 15
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- a comment describing the modifications made. The CHECKOUT
- command then extracts for "making" all the dependent files
- (header files) that will not be directly compiled. This is all
- the preparation we need in order to begin compiling.
-
- The FINI dummy target runs CHECKOUT one more time to make sure
- that all our source code files are extracted for editing. Keep
- in mind that when a file is extracted for making all the macros
- are expanded and the file is marked read-only. If errors were
- encountered during the make we want the source files ready to
- modify without any hassle.
-
- Step 2: Templates
- Step 2: Templates
-
- Most (recent) MAKE programs use a special construct called a
- "Template." A template tells the MAKE program how to build a
- target file from a source file without having to exactly specify
- the file name, only the extensions of the two.
-
- For example, NDMAKE uses the following template to tell it how to
- create a .OBJ file from a .C source file:
-
- # C -> OBJ
- .c.obj:
- ${CC} ${CFLAGS} -c $<
-
- The "${CC} ${CFLAGS} -c" are the command and options needed to
- run the 'C' compiler. During the make process the "$<" is
- replaced with the name of each .C source file that must be
- recompiled. This can also be used by CHECKOUT to extract the
- source file from the project database just before it is compiled.
- (Remember that our post-processing will extract it for editing at
- the end of the make run so we only need to extract it for
- making.)
-
- We can change this template to include the CHECKOUT command as
- follows:
-
- # C -> OBJ
- .c.obj:
- CHECKOUT -m PROJ $<
- ${CC} ${CFLAGS} -c $<
-
- This simple addition will now cause the compiler to work with
- source code files that have expanded macros.
-
- Enhancements
- Enhancements
-
- What we have just shown is the minimum needed to use PSCM with a
- MAKE program. There are a few enhancements we can use to improve
- PSCM's integration into our work methods.
-
-
-
-
- page 16 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Most (if not all) MAKE programs allow the use of macros. In the
- examples shown above the "${CC}" and "${CFLAGS}" are just macros.
- We can also use macros to further enhance our use of PSCM. By
- changing the references to "PROJ" in the above examples to
- "${PROJ}" and then setting the PROJ macro to the name of our
- project database we make the changes universal. All that we have
- to do to include PSCM in a different make control file is to copy
- the modified control lines to the new file and add the PREP and
- FINI dummy targets to the list of dependents for the primary
- target.
-
- Most MAKE programs also have an initialization file. This file
- is read when the program starts. It contains standard macros and
- templates used during the make process. It may be possible for
- you to modify the initialization file to include the CHECKOUT
- command. Note that this usually requires decision making and
- branching capabilities too since we don't want the make to fail
- just because we don't happen to have a project file. However, it
- is okay to specify a non-existent source file on the CHECKOUT
- command line; CHECKOUT will simply checkout nothing.
-
- You can also use the CHECKIN feature that allows entering
- comments from ASCII text files. Simply change the CHECKIN
- command in the PREP dummy target to include redirecting the
- contents of the comment file into CHECKIN. For example:
-
- CHECKIN -c ${PROJ} < COMMENTS
-
- This allows you to keep a running COMMENTS file that describes
- each change as you make it. You could also use a custom editor
- macro that extracts this information from the source code and
- copies it to this file. Either way it helps to further automate
- the make process.
-
- You should make sure to truncate the comments file to zero length
- after it has been used by CHECKIN. Note that this is not the
- same as deleting the file. If the file does not exist CHECKIN
- will not execute because DOS will fail to open the input file.
-
- The quickest way to truncate a file to zero length is with the
- following DOS command:
-
- IF 1 == 0 ECHO>COMMENTS
-
- Since "1" never equals "0" (at least we hope not) then the ECHO
- command will never execute. But DOS will truncate the COMMENTS
- file before it determines that it should skip the ECHO.
-
-
-
-
-
-
-
-
- PSCM v1.3 page 17
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- PSCM is ShareWare
- PSCM is ShareWare
- _________________
- _________________
-
- I have been a software developer for many years. During that
- time I have acquired and used many very good programs through the
- "ShareWare" system. ShareWare allows you to try a program before
- buying it. It does not mean the program is free, nor does it
- mean that it is a limited version of a commercial program.
-
- I wrote PSCM as an answer to my needs in software development. I
- first came across the idea of source code and revision management
- when I ported some code from DOS to Unix. The SCCS system on
- Unix was very neat, but horribly cryptic and cumbersome. Since
- then I have hunted for a good source code manager, but everything
- is either priced way out of my range or just wasn't designed to
- work with a MAKE program.
-
- If you try PSCM and you like it and intend to use it, a donation
- of $25 is suggested. Educational institutions may register PSCM
- for $15. With a donation of $40 I will send the latest version
- of PSCM, laser printed docs, and a BIG thank you. If you need a
- bunch of copies, contact me and we can work something out.
-
- To register your copy, print out and complete the registration
- form (REGISTER.FRM) and mail it to:
-
- J. Bart Henthorn
- 10607 E. Lowry Pl.
- Aurora, CO 80010-4035
-
- Please make payments by personal check or money order. I cannot
- accept credit card orders and it is never a good idea to send
- cash through the mail.
-
- If you have questions or comments about PSCM you can contact me
- by fax at (303) 341-7336.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- page 18 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Revision History
- Revision History
- ________________
- ________________
-
- Date Vers Comments
- 11/15/90 1.0 Initial Release: CHECKIN.EXE, CHECKOUT.EXE,
- DIFS.EXE, MRGS.EXE, ISIZE.EXE
-
- 11/18/90 1.1 Enhancements and Bug Fixes:
- Added support for Comments and Sets.
- Fixed bug regarding file selection in
- CHECKOUT.EXE
-
- 11/18/90 1.1a Fixed bug that caused wrong time/date stamps
- on files listed in a Set. The files were
- retrieved with the proper time and date,
- just the listing in the Set was wrong.
- Added mode to allow extracting Sets for
- Editing as well as Making.
-
- 12/03/90 1.2 New Version 1.2:
- Added support for revision comments placed in
- files extracted for making.
-
- 07/31/92 1.3 New Version 1.3:
- Added undo capability.
- Added comment listing for single files.
- Added listing of differences.
- Added SHOWDIFS.EXE program.
- Trap and handle Control+C and Control+Break.
- Prevent accidental overwrite of source file.
- Fixed various bugs.
- (Please see following page for details.)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- PSCM v1.3 page 19
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- Bugs Fixed and Enhancements Added to Version 1.3
- Bugs Fixed and Enhancements Added to Version 1.3
- ________________________________________________
- ________________________________________________
-
- 1. There was an obscure little bug that doesn't show up often,
- but when it does it is a booger to find. The PSCM.CFG file
- can hold seven strings that are expanded as macros when
- files are extracted from a project file. If one of these
- strings is exactly the right length the Microsoft fgets()
- function reads the carriage return (CR) but not the linefeed
- (LF). On the next call it reads the LF and sets the next
- string to an empty string and moves the remaining strings
- down one line. This bug is now fixed in 1.3.
-
- 2. I've done it, and I'm sure you've done it too; forget to
- include the project file name when trying to add new files
- to an existing project file. Prior versions promptly wrote
- over the first source file name, creating a new project file
- with that name. For example:
-
- CHECKIN -V0.0 FOO.C BAR.C
-
- When what you meant was:
-
- CHECKIN -V0.0 PROJ FOO.C BAR.C
-
- This little finger faux pas means that your brand new FOO.C
- module gets overwritten with a brand new project file named
- FOO.C. This bug has been fixed in version 1.3. CHECKIN now
- reports that the file FOO.C already exists and is not a
- project file.
-
- 3. CHECKIN, CHECKOUT, MRGS, DIFS and SHOWDIFS are now protected
- against use of the Control+C or Control+Break keys. Prior
- versions could do everything from quietly die (at the mild
- end) to completely trash your Project file (at the severe
- end). This behavior has now been fixed. CHECKOUT, MRGS,
- DIFS and SHOWDIFS will now happily ignore these keys.
- CHECKIN will behave slightly different.
-
- If you press either Control+C or Control+Break while CHECKIN
- is running or when you are entering a comment, the Project
- file will be politely shut down. If changes have been made
- to the Project file they will be undone before CHECKIN
- quits.
-
- IMPORTANT: Using Control+C or Control+Break to abort a
- IMPORTANT
- CHECKIN run also deletes any "Undo" information that was
- saved in the Project file before the run was begun. (See
- next section for more on Undo.) This means that if you
- start a CHECKIN run and then abort it, you cannot then
- further undo the Project file.
-
- 4. CHECKIN now supports an "Undo" command. This is a single
- level, one-time only undo. The most recent changes wrought
- by CHECKIN will be reversed. No source files on disk are
-
- page 20 PSCM v1.3
-
- PSCM -- The Project Source Code Manager July 31st, 1992
-
- modified; the Project file is the only file altered. You
- may only perform an undo once. CHECKIN will print an error
- message if there is no undo information in the Project file.
-
- To undo the previous CHECKIN session, use the following
- command:
-
- CHECKIN -U PROJ
-
- Each file will be listed as it is removed or reverted.
-
- IMPORTANT: This is an all or nothing proposition. You can
- not undo only certain files from the previous CHECKIN. All
- modifications made during the previous run will be undone.
-
- 5. The CHECKOUT List command (-L) will now display an extra
- line if undo information is present in the Project file.
-
- 6. The CHECKOUT Comment command (-C) has been enhanced to
- permit specifying which files should be listed. The display
- format changes when files are included on the command line.
- If no files are specified then the output format is the same
- as in version 1.2. If you do specify file names they will
- be listed one at a time with all related comments
- immediately following each individual name. The following
- is an example of the new report format:
-
- === DIFS.C =========================================
- Revision: 1.3.1 entered at 22:54:32 on 07/27/92
- Added Control-C handler to DIFS and MRGS
- ====================================================
-
- === MRGS.C =========================================
- Revision: 1.3.1 entered at 22:55:20 on 07/27/92
- Added Control-C handler to DIFS and MRGS
- ====================================================
-
- 7. It is sometimes helpful to see how a source file has been
- modified before it is checked in to the project database.
- The CHECKIN command now provides a new switch "-D" that
- performs this function. Before checking in the modified
- source files you can run "CHECKIN -D PROJ" to create a set
- of difference files. Each file has the same base name as
- the source file but with the extension "__D". The following
- is an example of the difference file format:
-
- < = Version on disk; > = Version checked in
-
- < DESC desc1;
- ----------------------------------------
- > DESC desc1, desc2;
-
-
-
-
- PSCM v1.3 page 21
-