Version Control
SCCS is a source management system which maintains versions of files; a record is kept with each set of changes of what the changes are, why they were made, and who made them and when. Old versions can be recovered, and different versions can be maintained simultaneously. In projects with more than one person, SCCS ensures that two people are not editing the same file at the same time.

All versions of the file, plus the log and other information, is kept in a file called the "s-file". There are three major operations that can be performed on the s-file:

• Get a file for viewing (not for editing). This operation retrieves a version of the file from the s-file. By default, the latest version is retrieved. This file is not intended for editing or changing in any way; any changes made to a file retrieved in this way will probably be lost.
• Get a file for editing. This operation also retrieves a version of the file from the s-file, but this file is intended to be edited and then incorporated back into the s-file. Only one person may be editing a file at one time.
• Merge a file back into the s-file. This is the companion operation to the step above. A new version number is assigned, and comments are saved explaining why this change was made.

SCCS s-file
The s-file is a single file that holds all the different versions of your file. The s-file is stored in differential format; i.e., only the differences between versions are stored, rather than the entire text of the new version. This saves disk space and allows selective changes to be removed later. Also included in the s-file is some header information for each version, including the comments given by the person who created the version explaining why the changes were made. Each set of changes to the s-file is called a delta.

The s-file is also checksum-ed, prohibiting direct manual changes to this file. In addition, any disk corruption are immediately discovered when the s-file is opened for processing.

SCCS l-file
The l-file is a single file that holds the lock information associated with a file (who locked the file and when).

SCCS d-file
The d-file is a single file that holds application-specific properties associated with a file (i.e. who created the file, the date/time the file was created, description of the contents). Properties are set/retrieved by the WebDAV PROPS and PROPPATCH methods.

Sambar Server SCCS
The Sambar Server uses a somewhat modified version of SCCS. While it is largely compatible with existing SCCS packages, there are a few notable exceptions:

• SCCS data is stored in the directory .DAV rather than SCCS. This is was done to consolodate the WebDAV properties and supplemental version control information in the same location.
• Binary content is automatically saved in binary form in the SCCS file regardless of whether flags indicate the content is binary. (Note: Binary content is determined by examining the first 1K of content, searching for non-ASCII values.) Binary content is stored in compressed form.

Binary Files
When checking files in via the Document Manager or directly via sccs the file can be identified as binary (-b with sccs create). The difference between a binary file and non-binary file is that "text-based" files (non-binary) use diff to to merge differences between versions. What this means is that after updating a file, only the differences with the previous version are stored (which is typically quite small). Binary files do not use the diff engine and instead, store the entire version of the file (compressed); this results in considerably larger s-files and generally slower access times.

Usage

NAME
     sccs - front end for the SCCS subsystem

SYNOPSIS
     sccs [ -r ] [ -dpath ] [ -ppath ] command [ flags ] [ args ]

DESCRIPTION
     sccs is a front end to the SCCS library used by the Sambar Server.
     Basically, sccs runs the command with the specified flags and args. Each
     argument is normally modified to be prepended with ``.DAV/s.''.

     Flags to be interpreted by the sccs program must be before the command
     argument.  Flags to be passed to the actual SCCS program must come after
     the command argument.  These flags are specific to the command and are
     discussed in the documentation for that command.

     Besides the usual SCCS commands, several ``pseudo-commands'' can be
     issued.  These are:

     edit      Equivalent to ``get -e''.

     delget    Perform a delta on the named files and then get new versions.
               The new versions will have id keywords expanded, and will not
               be editable.  The -m, -p, -r, -s, and -y flags will be passed
               to delta, and the -b, -c, -e, -i, -k, -l, -s, and -x flags will
               be passed to get.

     deledit   Equivalent to ``delget'' except that the ``get'' phase includes
               the ``-e'' flag.  This option is useful for making a
               ``checkpoint'' of your current editing phase.  The same flags
               will be passed to delta as described above, and all the flags
               listed for ``get'' above except -e and -k are passed to
               ``edit''.

     create    Creates an SCCS file, taking the initial contents from the file
               of the same name.  Any flags to ``admin'' are accepted.  If the
               creation is successful, the files are renamed with a comma on
               the front.  These should be removed when you are convinced that
               the SCCS files have been created successfully.

     fix       Must be followed by a -r flag.  This command essentially
               removes the named delta, but leaves you with a copy of the
               delta with the changes that were in it.  It is useful for
               fixing small compiler bugs, etc.  Since it doesn't leave audit
               trails, it should be used carefully.

     clean     This routine removes everything from the current directory that
               can be recreated from SCCS files.  It will not remove any files
               being edited.  If the -b flag is given, branches are ignored in
               the determination of whether they are being edited; this is
               dangerous if you are keeping the branches in the same
               directory.

     unedit    This is the opposite of an ``edit'' or a ``get -e''.  It should
               be used with extreme caution, since any changes you made since
               the get will be irretrievably lost.

     info      Gives a listing of all files being edited.  If the -b flag is
               given, branches (i.e., SID's with two or fewer components) are
               ignored.  If the -u flag is given (with an optional argument)
               then only files being edited by you (or the named user) are
               listed.

     check     Like ``info'' except that nothing is printed if nothing is
               being edited, and a non-zero exit status is returned if
               anything is being edited.  The intent is to have this included
               in an ``install'' entry in a makefile to insure that everything
               is included into the SCCS file before a version is installed.

     tell      Gives a newline-separated list of the files being edited on the
               standard output.  Takes the -b and -u flags like ``info'' and
               ``check''.

     diffs     Gives a ``diff'' listing between the current version of the
               program(s) you have out for editing and the versions in SCCS
               format.  The -r, -c, -i, -x, and -t flags are passed to get;
               the -l, -s, -e, -f, -h, and -b options are passed to diff. The
               -C flag is passed to diff as -c.

     print     Prints out verbose information about the named files.  -c.

     prs       Prints out the delta information about the named files.  All
               the prs(1) can be specified.

     The -r flag runs sccs as the real user rather than as whatever effective
     user sccs is ``set user id'' to.  The -d flag gives a root directory for
     the SCCS files.  The default is the current directory.  The -p flag
     defines the pathname of the directory in which the SCCS files will be
     found; ``SCCS'' is the default.  The -p flag differs from the -d flag in
     that the -d argument is prepended to the entire pathname and the -p
     argument is inserted before the final component of the pathname.  For
     example, ``sccs -d/x -py get a/b'' will convert to ``get /x/a/y/s.b''.
     The intent here is to create aliases such as ``alias syssccs sccs
     -d/usr/src'' which will be used as ``syssccs get cmd/who.c''.  Also, if
     the environment variable PROJECTDIR is set, its value is used to
     determine the -d flag. If it begins with a slash, it is taken directly;
     otherwise, the home directory of a user of that name is examined for a
     subdirectory ``src'' or ``source''.  If such a directory is found, it is
     used.

     Certain commands (such as admin) cannot be run ``set user id'' by all
     users, since this would allow anyone to change the authorizations.  These
     commands are always run as the real user.

EXAMPLES
     To get a file for editing, edit it, and produce a new delta:

          sccs get -e file.c
          ex file.c
          sccs delta file.c

     To get a file from another directory:

          sccs -p/usr/src/sccs/s. get cc.c

     or

          sccs get /usr/src/sccs/s.cc.c

     To make a delta of a large number of files in the current directory:

          sccs delta *.c

     To get a list of files being edited that are not on branches:

          sccs info -b

     To delta everything being edited by you:

          sccs delta `sccs tell -u`

     In a makefile, to get source files from an SCCS file if it does not
     already exist:

          SRCS = 
          $(SRCS):
               sccs get $(REL) $@

Limitations

• Not authorization or authentication security is enforced when using the command-line utility.
• Not all "traditional" SCCS command-line options are supported.
• No other SCCS utilities (i.e. delta, admin) are provided.
• The bin/sccs utility does not perform any shell expansion (i.e. sccs checkin *.htm will fail).
• All actions must be performed in the directory where the file and repository (.DAV directory) are found. Only relative paths are allowed (i.e. sccs checkin foo.htm NOT sccs checkin /xx/foo.htm).