home *** CD-ROM | disk | FTP | other *** search
/ C!T ROM 2 / ctrom_ii_b.zip / ctrom_ii_b / PROGRAM / C / PSCM12 / READ.ME < prev    next >
Text File  |  1990-12-03  |  28KB  |  745 lines
  1.  
  2.  
  3.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  4.  
  5.  
  6.                        PSCM - Project Source Code Manager
  7.         
  8.         PSCM  consists of two main programs: CHECKIN and CHECKOUT.  These 
  9.         two  programs  control  a  project  database  that  contains  the 
  10.         complete  source code and support files for a project. The  basic 
  11.         function  of PSCM is to maintain and archive various versions  of 
  12.         the  project  as it evolves. At any point in time  it  should  be 
  13.         possible  to retrieve the full set of files needed to create  the 
  14.         project at any point in time.
  15.         
  16.         PSCM  manages  the  different revisions by  assigning  a  Version 
  17.         Number  to each different version of the files. This  number  has 
  18.         three parts as follows:
  19.         
  20.              M.N.R  where:
  21.         
  22.              M    The major version number. This number must be at  least 
  23.                   1 and as high as 32767.
  24.              N    The minor version number. This number may range from  0 
  25.                   to 32767.
  26.              R    The  revision number. This number may range from  0  to 
  27.                   32767  and is used to indicate  intermediate  revisions 
  28.                   between releases.
  29.         
  30.         When a project's files are identified by only the major and minor 
  31.         version  numbers,  this is referred to as a "Version".  When  the 
  32.         revision number is included, this is called an "Instance". When a 
  33.         set  of  files is retrieved for a particular  Version,  the  most 
  34.         recent Instance of all files is retrieved. It is also possible to 
  35.         retrieve a specific revision of a file.
  36.         
  37.         The  database  maintains  an internal  directory  of  files  that 
  38.         constitute  a project set. This directory is only  maintained  at 
  39.         the Version level, not at the Instance level. This means that  if 
  40.         a  file  is deleted, it cannot be retrieved at a  prior  Instance 
  41.         within the same Version.
  42.         
  43.         PSCM  stores only the latest instance of a file in the  database. 
  44.         Prior instances are stored as "Difference Scripts". These scripts 
  45.         are generated and used by the two PSCM support programs: DIFS and 
  46.         MRGS. DIFS compares two files and produces a file that  describes 
  47.         how they differ. MRGS uses a script file and the original  source 
  48.         file to produce the second source file.
  49.         
  50.         PSCM also allows the inclusion of comments in the database  file. 
  51.         When  one or more files have been changed, and new  Instances  of 
  52.         the  files are added to the database, an optional comment may  be 
  53.         generated  and  saved. Along with the comment is a  list  of  the 
  54.         files  modified and their revision level and file date and  time. 
  55.         These comments may be either listed one at a time or all comments 
  56.         at once.
  57.         
  58.         During development it may be required to take a "Snapshot" of the 
  59.         current revision level of all files in the database. PSCM  allows 
  60.  
  61.  
  62.         PSCM                                                      page 1
  63.  
  64.  
  65.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  66.  
  67.  
  68.         this function through the use of "Sets". When a Set is created, a 
  69.         record  is made of all files at their most recent Instance.  This 
  70.         is stored along with a comment which can be used to describe  the 
  71.         Set.  At any point in time it is possible to recreate  the  exact 
  72.         state of these files using the CHECKOUT program's Set command. It 
  73.         is also possible to generate a list of all Sets in the database.
  74.         
  75.         The PSCM Configuration File
  76.         
  77.         PSCM  uses a configuration file to store some  basic  information 
  78.         used  when expanding some of the special macro strings  described 
  79.         later.  The  configuration file is an eight line text  file.  The 
  80.         first  line in the file is called the "System" line. The text  of 
  81.         the first line is used when expanding the System Name macro.  The 
  82.         remaining seven lines are called "User Parameters". They are used 
  83.         when expanding the seven User macros.
  84.         
  85.         When  the CHECKOUT program begins execution, it attempts to  open 
  86.         the configuration file "PSCM.CFG" in the current directory. If it 
  87.         cannot find the file in the current directory, and you are  using 
  88.         DOS   version  3.0  or  later,  it  will  attempt  to  load   the 
  89.         configuration file from the directory where the CHECKOUT  program 
  90.         was loaded from. This allows you to have a default  configuration 
  91.         stored in the same directory as the CHECKOUT.EXE file and to have 
  92.         a project specific configuration in the working directory.
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120.  
  121.  
  122.  
  123.  
  124.         page 2                                                      PSCM
  125.  
  126.  
  127.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  128.  
  129.  
  130.         The Project Source Files
  131.         
  132.         A Project's source files are plain ASCII text files that  contain 
  133.         the source code for a project. The source files may also  include 
  134.         the various support files used to create and maintain the project 
  135.         such  as  a  make file and batch files.  For  example,  the  PSCM 
  136.         project has several 'C' code source files, a couple of 'C' header 
  137.         files,  a make file and a few batch files. Taken together,  these 
  138.         files  are all that is necessary to recreate the  entire  project 
  139.         from scratch.
  140.         
  141.         -----------------------------------------------------------------
  142.         NOTE      PSCM can only work with plain ASCII text files. It will 
  143.                   not  handle word processor files properly. The  various 
  144.                   control  codes in most word processor files  will  give 
  145.                   the PSCM database file serious brain damage.
  146.         -----------------------------------------------------------------
  147.         
  148.         The Project Database File
  149.         
  150.         The  Project Database file is used to hold all information  about 
  151.         the  project's source files. There is no requirement on the  name 
  152.         of the file, however the convention is to name it the same as the 
  153.         project with no extension. For example, my project file for  PSCM 
  154.         is  named "PSCM". The project database file need not even  be  in 
  155.         the same directory as the rest of the project files. This  allows 
  156.         you  to  place the project file on another drive  or  in  another 
  157.         directory for that added "Peace of Mind."
  158.         
  159.         The Item File System (IFS)
  160.         
  161.         PSCM uses a database manager called "The Item File System".  This 
  162.         DBMS allows records in the database to be of varying lengths.  It 
  163.         is  also very fast because it uses a hashing algorithm  to  store 
  164.         the records. When a project file is first created (by the CHECKIN 
  165.         program) it is given a default size (called a "Modulo") of 47. As 
  166.         the project database file grows it may be necessary to resize the 
  167.         file  to  improve retrieval speed. The ISIZE program is  used  to 
  168.         resize the project database file. Use the following command:
  169.         
  170.              ISIZE -r PROJECT
  171.         
  172.         The ISIZE program will inspect the project database file and then 
  173.         create a new file with a new size and copy all items from the old 
  174.         file to the new file. It will then delete the old file and rename 
  175.         the new file to the old file name.
  176.  
  177.  
  178.  
  179.  
  180.  
  181.  
  182.  
  183.  
  184.  
  185.  
  186.         PSCM                                                      page 3
  187.  
  188.  
  189.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  190.  
  191.  
  192.         The CHECKIN Program
  193.         
  194.         The CHECKIN program is used to add project files to the  database 
  195.         and to create new Versions or Instances of files. CHECKIN is also 
  196.         used to add comments to the database and to create project Sets.
  197.         
  198.         Adding New Files to a Project Database
  199.         
  200.         When  adding  one or more new files to the project  database,  or 
  201.         when  creating a new Version level, the Version numbers  must  be 
  202.         specified via a command line switch as follows:
  203.         
  204.              CHECKIN -vM.N PROJECT FILE1.C FILE2.C ... FILEn.C
  205.         
  206.         The  '-v' switch is used to specify the major and  minor  version 
  207.         numbers.  Note that the revision number is not specified,  it  is 
  208.         set to 0 by the program. If a copy of the file already exists  at 
  209.         the specified Version level, an error will occur.
  210.         
  211.         Updating Files in the Project Database
  212.         
  213.         To  create  a  new Instance of an existing  file,  the  following 
  214.         command line is used:
  215.         
  216.              CHECKIN -i PROJECT FILE1.C FILE2.C ... FILEn.C
  217.                   -or-
  218.              CHECKIN -i PROJECT
  219.                   -or-
  220.              CHECKIN -iM.N PROJECT FILE1.C FILE2.C ... FILEn.C
  221.                   -or-
  222.              CHECKIN -iM.N PROJECT
  223.         
  224.         When no file names are specified on the CHECKIN command line, all 
  225.         source files that have been modified since they were last checked 
  226.         in are updated. This is a shorthand way of updating all  modified 
  227.         files.
  228.         
  229.         The  first command form is used to create new Instances  for  the 
  230.         specified  files  at the most recent Version  level.  The  second 
  231.         command  is the same except that all modified files in  the  most 
  232.         recent Version are updated to a new Instance. These two forms are 
  233.         the most common used in project management.
  234.         
  235.         The third and fourth commands are similar to the first two except 
  236.         a  specific Version level is updated instead of the most  recent. 
  237.         These command forms are used when a previous CHECKOUT was run  to 
  238.         retrieve a Version other than the most recent.
  239.         
  240.         Adding Comments to the Project Database File
  241.         
  242.         The '-i' switch is used to create new Instances of source  files. 
  243.         But it is also possible to add a comment record at the same time. 
  244.         The  following  commands behave the same except  that  they  also 
  245.         allow an optional comment record to be created and saved with the 
  246.  
  247.  
  248.         page 4                                                      PSCM
  249.  
  250.  
  251.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  252.  
  253.  
  254.         files. The comment record contains one or more lines of text  and 
  255.         a list of the files updated. The following command forms are used 
  256.         to create comment records:
  257.         
  258.              CHECKIN -c PROJECT FILE1.C FILE2.C ... FILEn.C
  259.                   -or-
  260.              CHECKIN -c PROJECT
  261.                   -or-
  262.              CHECKIN -cM.N PROJECT FILE1.C FILE2.C ... FILEn.C
  263.                   -or-
  264.              CHECKIN -cM.N PROJECT
  265.         
  266.         Saving a Set of Files in the Database
  267.         
  268.         During the development process it may be useful to save a  record 
  269.         of the current revision level of all files in the database.  This 
  270.         record  is called a "Set". It is commonly used as a place  marker 
  271.         to  indicate  where specific test versions of  the  project  were 
  272.         generated  and released. For example, if you are in the habit  of 
  273.         releasing  preliminary versions to a small group of testers,  the 
  274.         Set  function can be used to regenerate the source code used  for 
  275.         each tester's version of the program.
  276.         
  277.         The command used to generate a Set is:
  278.         
  279.              CHECKIN -s PROJECT
  280.                   -or-
  281.              CHECKIN -sM.N PROJECT
  282.         
  283.         Note  that no file names are specified on the command line.  This 
  284.         is  because  the Set command generates and saves a  list  of  all 
  285.         files in the database. The first command form will generate a set 
  286.         for  the  most recent Version, while the second form is  used  to 
  287.         create a set for a specified version.
  288.         
  289.         -----------------------------------------------------------------
  290.         NOTE      None of the CHECKIN command forms will alter the source 
  291.                   files. They are left on disk exactly as before  CHECKIN 
  292.                   was run.
  293.         -----------------------------------------------------------------
  294.  
  295.  
  296.  
  297.  
  298.  
  299.  
  300.  
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.         PSCM                                                      page 5
  311.  
  312.  
  313.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  314.  
  315.  
  316.         Special Macros in Source Files
  317.         
  318.         When  files  are retrieved for editing, certain  special  "Macro" 
  319.         strings are left in the unexpanded form. When files are retrieved 
  320.         for  making (i.e. compiling, assembling, etc.) these  Macros  are 
  321.         expanded. The Macros can be used to specify version numbers, file 
  322.         dates and times, file names, etc.
  323.         
  324.         The  Macros  are  used to place  information  about  the  system, 
  325.         project,  or  file  in the text of the file.  When  the  file  is 
  326.         retrieved   for  making,  the  Macros  are  replaced   with   the 
  327.         information  specified.  There  are two types of  date  and  time 
  328.         macros.  One  form is used to place the current system  date  and 
  329.         time in the file. This is the system date and time when the  file 
  330.         is retrieved. The other form is used to place the file's time and 
  331.         date  in  the  text.  This  is the date  and  time  of  the  last 
  332.         modification to the file.
  333.         
  334.         The Macros are as follows:
  335.         
  336.              @#T  System Time in the form hh:mm:ss
  337.              @#D  System Date in the form mm/dd/yy
  338.              @#P  Project name
  339.              @#S  System name from the PSCM config file
  340.              @#1  User parameter 1 from the PSCM config file
  341.              @#2  User parameter 2 from the PSCM config file
  342.              @#3  User parameter 3 from the PSCM config file
  343.              @#4  User parameter 4 from the PSCM config file
  344.              @#5  User parameter 5 from the PSCM config file
  345.              @#6  User parameter 6 from the PSCM config file
  346.              @#7  User parameter 7 from the PSCM config file
  347.         
  348.              @#v  Version number in the form M.N
  349.              @#r  Revision number in the form M.N.R
  350.              @#M  Major version number
  351.              @#N  Minor version number
  352.              @#R  Revision number
  353.         
  354.              @#d  File date in the form mm/dd/yy
  355.              @#t  File time in the form hh:mm:ss
  356.              @#f  File name and extension in the form filename.ext
  357.              @#F  File name part only (no extension)
  358.         
  359.              @#c  Revision history comments
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.         page 6                                                      PSCM
  373.  
  374.  
  375.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  376.  
  377.  
  378.         The  '@#c' macro is slightly different than all the others.  When 
  379.         it  is processed, it puts the revision history comments  for  the 
  380.         file in the text. The part of the line already printed is put  at 
  381.         the beginning of each line before it is inserted in to the  text. 
  382.         For example, if the lines:
  383.         
  384.              /*
  385.               * @#c */
  386.         
  387.         are in the source text, they will be expanded to look like:
  388.         
  389.              /*
  390.               *
  391.               * Revision M.N.R entered at HH:MM:SS on MM/DD/YY
  392.               * Comment line 1
  393.               *
  394.               * Revision M.N.R entered at HH:MM:SS on MM/DD/YY
  395.               * Comment line 1
  396.               * Comment line 2
  397.               *
  398.               *  */
  399.         
  400.         Only  those  comments entered when a file was  updated  and  then 
  401.         checked  in using the CHECKIN option '-c' will be  printed.  Even 
  402.         though the comment may have been entered when more than one  file 
  403.         was updated, the comment text will be printed if the current file 
  404.         was included in the update.
  405.         
  406.         The  comment  text is placed in the text file starting  with  the 
  407.         most recent revision and proceeding to the oldest. When a file is 
  408.         extracted at a specific revision, only those comments which  were 
  409.         entered  before or at the revision are placed in the file. If  no 
  410.         comments are found, the '@#c' macro is simply discarded.
  411.  
  412.  
  413.  
  414.  
  415.  
  416.  
  417.  
  418.  
  419.  
  420.  
  421.  
  422.  
  423.  
  424.  
  425.  
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.         PSCM                                                      page 7
  435.  
  436.  
  437.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  438.  
  439.  
  440.         The CHECKOUT Program
  441.         
  442.         The  CHECKOUT  program is used to retrieve files  from  the  most 
  443.         recent  or a specified Version level. The files can be  retrieved 
  444.         for one of two purposes: Editing or Making.
  445.         
  446.         Retrieving for Editing or Making
  447.         
  448.         When files are retrieved for editing, all special Macros are left 
  449.         in  their  unexpanded form and the file is written to disk  as  a 
  450.         modifiable file. When files are retrieved for making, the special 
  451.         Macros  are replaced by the appropriate information and the  file 
  452.         is marked read-only. This prevents modification of the file.
  453.         
  454.         When  a  file is retrieved (either for editing or making)  it  is 
  455.         actually  retrieved  if the file on disk is  different  than  the 
  456.         retrieved  version  or  the last version was  retrieved  for  the 
  457.         opposite purpose. For example, if a file is retrieved for editing 
  458.         and  the version on disk is different (i.e. has a different  date 
  459.         and  time  stamp) then the file will be written to disk.  If  the 
  460.         file  is the same but was last retrieved for editing and  is  now 
  461.         being  retrieved  for making, the file will be written  to  disk. 
  462.         Note  that when a file is checked in (using the CHECKIN  program) 
  463.         the file on disk is assumed to be retrieved for editing.
  464.         
  465.         The command line for CHECKOUT is as follows:
  466.         
  467.              CHECKOUT -e[M.N[.R]] PROJECT [FILE1.C FILE2.C ... FILEn.C]
  468.                   -or-
  469.              CHECKOUT -m[M.N[.R]] PROJECT [FILE1.C FILE2.C ... FILEn.C]
  470.         
  471.         The  '-e' switch is used to retrieve files for editing. The  '-m' 
  472.         switch is used to retrieve files for making. Only one is  allowed 
  473.         on the command line.
  474.         
  475.         When  the  Version level is omitted, the most recent  version  is 
  476.         retrieved.  If  the Revision number is omitted, the  most  recent 
  477.         Instance  is retrieved. Note that you must specify a  Version  in 
  478.         order to specify a Revision.
  479.         
  480.         If  you  do not specify any file names on the command  line,  all 
  481.         files  which  are  different than the version  on  disk  will  be 
  482.         retrieved.  If one or more files are named in the  command,  only 
  483.         those files will be retrieved. Note that a file will be retrieved 
  484.         only  if the version on disk is different (has a  different  time 
  485.         and date) or was last retrieved for the opposite purpose (editing 
  486.         versus making.)
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.         page 8                                                      PSCM
  497.  
  498.  
  499.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  500.  
  501.  
  502.         Listing the Files in the Project Database
  503.         
  504.         The CHECKOUT program is also used to list files in a specific  or 
  505.         the latest version. The listing shows each file's name, time  and 
  506.         date,  and  full version and revision number. The command  is  as 
  507.         follows:
  508.         
  509.              CHECKOUT -l[M.N[.R]] PROJECT [FILE1.C FILE2.C ... FILEn.C]
  510.         
  511.         As with the other forms of the CHECKOUT command, the version  and 
  512.         revision numbers and the file names are optional.
  513.         
  514.         Listing Comments in the Project Database
  515.         
  516.         CHECKOUT  can  also  list  the  comment  records  stored  in  the 
  517.         database. When new Instances of files are created using the  '-c' 
  518.         switch  in the CHECKIN program, a comment record is  saved  along 
  519.         with  a  list of the files that were updated. CHECKOUT  can  list 
  520.         either  a  specified comment record or all comment  records.  The 
  521.         commands used are as follows:
  522.         
  523.              CHECKOUT -c[M.N] PROJECT
  524.                   -or-
  525.              CHECKOUT -cM.N.R PROJECT
  526.         
  527.         The first command form is used to list all comment records. If  a 
  528.         Version  is specified then all comments for that version will  be 
  529.         listed. Otherwise all comments for the latest version are listed.
  530.         
  531.         The  second  command  form is used to  list  a  specific  comment 
  532.         record.  As  with  files,  all comment  records  are  assigned  a 
  533.         Revision  number.  This  revision number is not  related  to  the 
  534.         revision numbers of the other files in the database, it is simply 
  535.         used to track sequential comments.
  536.         
  537.         The output from the Comment command is sent to STDOUT. This means 
  538.         that  it may be redirected to a file or piped to another  program 
  539.         if desired. (For a complete discussion of redirection and  pipes, 
  540.         please refer to your DOS manual.)
  541.         
  542.         Listing or Retrieving Files Sets
  543.         
  544.         The CHECKOUT program is also used to list or retrieve Sets  saved 
  545.         in  the  project  database using the  CHECKIN  program.  The  Set 
  546.         command forms are as follows:
  547.         
  548.              CHECKOUT -s[M.N] PROJECT
  549.                   -or-
  550.              CHECKOUT -sM.N.R PROJECT
  551.                   -or-
  552.              CHECKOUT -rM.N.R PROJECT
  553.         
  554.         The  first  form is used to list all Sets saved  in  the  project 
  555.         database file. If a Version is specified then only Sets for  that 
  556.  
  557.  
  558.         PSCM                                                      page 9
  559.  
  560.  
  561.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  562.  
  563.  
  564.         version are listed. If the Version is omitted, then the Sets  for 
  565.         the  most  recent Version are listed. The  listing  includes  the 
  566.         comment  saved when the Set was created along with a list of  all 
  567.         files and their revisions that were saved in the Set. The listing 
  568.         is  sent to STDOUT so it may be redirected to a file or piped  to 
  569.         another program.
  570.         
  571.         To  retrieve the files from a specific Set, the second and  third 
  572.         command  forms  are used. An exact Version and Instance  must  be 
  573.         specified.  Note  that the Revision numbers of the Sets  are  not 
  574.         related  to  the  Revision  numbers  for  files.  All  files  are 
  575.         retrieved at the Version and Instance specified in the Set.
  576.         
  577.         When the '-s' switch is used, the files are retrieved for Making, 
  578.         so  all special macros are expanded and the files are  marked  as 
  579.         read-only  to prevent modification. If the '-r' switch  is  used, 
  580.         then  the  files are retrieved for Editing. All macros  are  left 
  581.         unexpanded and the files are made modifiable. Once a Set has been 
  582.         retrieved, the files may be used to rebuild the project or simply 
  583.         viewed or printed as desired.
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598.  
  599.  
  600.  
  601.  
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615.  
  616.  
  617.  
  618.  
  619.  
  620.         page 10                                                      PSCM
  621.  
  622.  
  623.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  624.  
  625.  
  626.         PSCM is ShareWare
  627.         
  628.         I have been a software developer for many years. During that time 
  629.         I  have  acquired and used many very good  programs  through  the 
  630.         "ShareWare" system. ShareWare allows you to try a program  before 
  631.         buying it. It does not mean the program is free, nor does it mean 
  632.         that it is a limited version of a commercial program.
  633.         
  634.         I wrote PSCM as an answer to my needs in software development.  I 
  635.         first came across the idea of source code and revision management 
  636.         when I ported some code from DOS to Unix. The SCCS system on Unix 
  637.         was very neat, but horribly cryptic and cumbersome. Since then  I 
  638.         have  hunted  for a good source code manager, but  everything  is 
  639.         either priced way out of my range or just wasn't designed to work 
  640.         with a MAKE program.
  641.         
  642.         PSCM  is designed to work with most types of MAKE programs.  When 
  643.         files  are retrieved they are given the proper time and  date  so 
  644.         MAKE  can make the right decisions about what should be  rebuilt. 
  645.         PSCM  will only store or retrieve files that are  different  thus 
  646.         easing  the  control issues. All in all I like it. But  then  I'm 
  647.         biased, I wrote it.
  648.         
  649.         If you try PSCM and you like it and intend to use it, a  donation 
  650.         of  $25 is suggested. Educational institutions may register  PSCM 
  651.         for $15. With a donation of $40 I will send the latest version of 
  652.         PSCM,  laser  printed docs, and a BIG thank you. If  you  need  a 
  653.         bunch of copies, contact me and we can work something out.
  654.         
  655.         To  register your copy, print out and complete  the  registration 
  656.         form (REGISTER.FRM) and mail or FAX it to:
  657.         
  658.              J. Bart Henthorn
  659.              10607 E. Lowry Pl.
  660.              Aurora, CO  80010-4035
  661.              FAX: (303) 341-7336
  662.         
  663.         Visa  and  MasterCard credit cards are welcome.  But  come  early 
  664.         'cause I don't accept American Express!
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674.  
  675.  
  676.  
  677.  
  678.  
  679.  
  680.  
  681.  
  682.         PSCM                                                      page 11
  683.  
  684.  
  685.         PSCM -- The Project Source Code Manager        December 3rd, 1990
  686.  
  687.  
  688.         Revision History
  689.         
  690.         Date      Vers      Comments
  691.         11/15/90  1.0       Initial  Release: CHECKIN.EXE,  CHECKOUT.EXE, 
  692.                               DIFS.EXE, MRGS.EXE, ISIZE.EXE
  693.         
  694.         11/18/90  1.1       Enhancements and Bug Fixes:
  695.                             Added support for Comments and Sets.
  696.                             Fixed   bug  regarding  file   selection   in 
  697.                               CHECKOUT.EXE
  698.         
  699.         11/18/90  1.1a      Fixed bug that caused wrong time/date  stamps 
  700.                               on  files listed in a Set. The  files  were 
  701.                               retrieved  with the proper time  and  date, 
  702.                               just the listing in the Set was wrong.
  703.                             Added  mode  to  allow  extracting  Sets  for 
  704.                               Editing as well as Making.
  705.         
  706.         12/03/90  1.2       New Version 1.2:
  707.                             Added support for revision comments placed in 
  708.                               files extracted for making.
  709.         
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730.  
  731.  
  732.  
  733.  
  734.  
  735.  
  736.  
  737.  
  738.  
  739.  
  740.  
  741.  
  742.  
  743.  
  744.         page 12                                                      PSCM
  745.