sccsput - SCCS check-in script


       sccsput [options] [file-specifications]


       Sccsput is a simple, easy to use interface to sccs (source code control
       system).  For each file  specified  as  input,  it  checks  differences
       against the previously archived version and prompts you for change his-
       tory comments.


       Sccsput uses the sccs utilities admin and delta to maintain versions of
       a  given source file in a dependent directory named "SCCS".  It is more
       than an integration of the admin and delta utilities, however:

       o   It checks to ensure that each file is indeed a text file  (so  that
           you do not accidentally archive ".o" files, for example).

       o   If  you  give  sccsput a directory name, it will recur, checking-in
           files in the directory.

       o   For each file which has a corresponding "s." file, sccsput compares
           the two (using diff) and pipes the result through the pager.

       o   An option is provided so that you may direct sccsput to perform the
           differencing without checking the file into sccs.

       o   The "s." file is post-processed by sccsput  so  that  the  check-in
           date matches the file's modification date.

       The  last  point  is the fundamental advantage offered by sccsput.  The
       ordinary sccs methodology uses the current date as the  check-in  date.
       This  works  well  only  for  large projects in which a central project
       administrator is responsible for controlling  the  versions  of  source
       files.  It does not work well for small projects, for which sccs's pri-
       mary advantage is its compact storage of multiple versions of a file.

       By using the file's modification date as a reference, you can more eas-
       ily back up to a meaningful version - by date, rather than version num-
       ber.  (By working exclusively in terms of modification date,  you  lose
       the  ability  to specify sccs release numbers - given the complexity of
       sccs's interface for release and version numbers, this is probably  not
       such a great loss).

       Sccsput  integrates  all  of  the  functions  used in the sccs check-in
       process into one utility program.


       Some of the options which you may specify to sccsput are passed through
       to the underlying utilities.  Others represent extensions:

       -b     is passed to diff, and directs it to ignore trailing blanks on a
              line, and to treat repeated blanks as a single blank.

       -c     directs sccsput to use cat rather than the PAGER (usually  more)
              to  display  differences.  This is most useful in an Apollo pad,
              since the more program would otherwise switch to VT100  emulator

       -f     forces  a  check-in,  ignoring  the  output of the file utility,
              which identifies text files.

       -l file
              causes sccsput to generate a log-file of  the  files  which  are
              processed,  and all differences which are encountered.  The log-
              file is inherited in recursion to lower directory levels  (i.e.,
              it is written to the same place).

       -n     instructs  sccsput to test for differences, but not to check the
              files into sccs.

       -s     suppresses some of the messages  generated  by  the  sccs  delta
              utility describing the number of lines changed, etc.


       The  sccsput utility is designed for use in small development projects.
       The methodology for this tool follows:

       o   Develop source files "normally".  Each  file  should  contain  sccs
           keywords  (see  get (1))  so  that  you will be able to distinguish
           checked-out files.  The sccs keywords should appear at the  top  of
           your  source  file,  for  consistency.  In C language programs, the
           convention is to make a string which will permit the  what  utility
           to show the versions of the modules which make up a program:

            #ifndef  lint
            static   char    sccs_id[] = "@(#)sccsput.doc    1.1 88/05/05

       o   Periodically  archive  (with sccsput) those versions of files which
           you wish to keep (You should never have  programs  which  have  new
           features  which  you wish to keep, while there are defects in other
           parts of the program - that would be an unsound approach to  devel-

       o   When  you reach the point of releasing the program, ensure that all
           source files have been checked-in.  The directory editor  (ded)  is
           useful for reviewing the check-in dates.

       o   Copy  the  directory  containing your program to the release direc-
           tory.  Purge all files, except those which are stored in  the  sccs
           subdirectories.   Use  sccsget  to extract the files (the unadorned
           get utility will work, of course, but it retains the file modifica-
           tion dates).

       o   Ensure  that  all files have been checked-in and released.  You may
           use diff to compare the directories - the only  differences  should
           be the substituted sccs keywords.

       o   Build  the  released  version of your program.  All files should be
           present.  No embedded path names should refer to  your  development
           copy.   To ensure good isolation, you may change the permissions on
           your development directory temporarily.

       Sccsput checks your source file out after the check-in,  automatically.
       This  is  done  to  facilitate development.  A check-in simply adds the
       latest changes to a file onto the archive.

       When checking files into sccs, it is a good idea to  make  a  test  run
       (using  the  "-n" option) so that you can inspect the differences.  For
       example, you may have forgotten to remove (or bypass) debugging  stubs.
       Or,  you  may  have been editing a checked-out file (with the sccs key-
       words substituted).  Sccsput would archive this anyway.  If you forget,
       and  wish  to  kill  the check-in, wait until the "comments?" prompt is
       issued by the delta utility.  At this point you may kill sccsput  with-
       out having to clean up temporary files.

       If  you  do not have write-permission on the "SCCS" directory, but wish
       to review changes, use the "-n" option.   The  intermediate  files  are
       written in the /tmp directory.


       Sccsput  is  a  Bourne shell script.  On Apollo DOMAIN/IX, it uses Sys-
       tem 5 features including dirname (1) and getopt (1).

       Environment variables imported by sccsput include:

       Sccsput also uses the following environment variables:

       NOTE   Provides a default value for the delta comments.   Normally  you
              should  provide case-by-case comments for each file.  This vari-
              able is provided so that other programs can invoke sccsput.   If
              the  NOTE  variable  is defined (i.e., non-null) it is used; you
              will not be prompted for comments.

       PAGER  identifies the program to use in displaying differences  between
              the  file which is being checked in, and the previously archived
              version.  There may be a lot of differences - more than  can  be
              shown on one screen.

              specifies  the  directory  into  which  the  sccs "s." files are
              stored.  If no specified, sccsput assumes "SCCS".


       Sccsput uses the following files

              the Bourne shell script

              A utility which invokes admin or delta as required, and modifies
              the  sccs  "s."   file  after check-in so that the check-in date
              matches the file's modification date.


       Make sccsput clean up temporary files if it is interrupted.

       Provide a mechanism for inserting dummy version numbers so that sccsput
       can  bump  the release number (for genuine major releases).  Currently,
       the SID's are restricted to 1.1, 1.2, 1.3, etc.


       putdelta,  sccsget,  ded,  admin (1),  delta (1),  diff (1),   get (1),
       rmdel (1), what (1)


       Thomas Dickey (Software Productivity Consortium).