Home | Schilytools |
The POSIX standard Source Code Control System

Welcome to the SCCS project

SCCS is an implementation of the POSIX standard Source Code Control System. It provides actively maintained code based on the original UNIX SCCS code OpenSourced by Sun as part of OpenSolaris and was made portable to other platforms.

Download the stable SCCS source.
Download recent development versions with the schily source consolidation (see schily-*.tar.* archives).

Read the SCCSman pages.

Check the SCCS development area at SourceForge.

The The Story of How SCCS Was Invented, an essay from Marc J. Rochkind.Marc J. Rochkind

The SCCS vs. RCS FAQ, comparing features and performance.

The SCCS version 4 announcement, AT&T 1977

The SCCS 1972-2011, History and Future of SCCS. Talk held at BLIT-2011 (German).
The History and Revival of SCCS. Talk held at CLT-2012 (German).

Please help to discuss the upcoming distributed SCCS v6 implementation

  • Subscribe to sccs developers mailing list and contribute your ideas
  • Discuss how to bracket a bunch of file deltas to a changeset
  • Discuss how to make releases safe against tampering
  • Discuss how to implement internet access to a remote SCCS repository
  • Discuss how to implement access control for internet access

  • What are the disadvantages of SCCS?

  • SCCS v4 uses local time and no timezone in s. history files and p. files (fixed for s. files with SCCS v6)
  • The p. file format cannot be fixed as it is part of the POSIX standard, but local time based stamps are not a problem in transitional files

    What are the advantages of SCCS?

  • SCCS is the first version control system, originally written in 1972 by Marc J. Rochkind at Bell Labs
  • The SCCS history file format is kept compatible since SCCSv4 has been published on February 18 1977
  • Fast operation compared to other Source Control systems, entering 52000 files (560 MB) from OpenSolaris sources takes 15 seconds
  • No known "SCCS caused" data loss since at least 30 years, the curruptions in the BSD sources are a result of a hard disk crash (according to Kirk McKusick)
  • One Source file results in one SCCS history file, so a file loss does not affect the whole project
  • Easy to understand format of the history files that allows manual intervention
  • Checksums and interleaved deltas (weave file format) grant file integrity and immediate detection of corruption
  • Interleaved deltas (weave file format) allow fast extract by using a single linear read on the history file at a cost of O(n) (a time slider application allows 100 MB/s refresh rate for different version of a single file)
  • Interleaved deltas allow to create annotated files (with revision, date and contributor) on a line by line base at no cost.
  • Support for binary files using uuencoded SCCS history (set up via admin -b)
  • SCCS is much faster than competing syststems (e.g. RCS, CVS and others) - typically 6x faster than RCS (never slower than RCS)

    What are the advantages of a Sun based SCCS over other implementations?

  • Unlimited line length in the file content
  • Because we use Solaris diff(1), the text SCCS history format prevents only ^A at the beginning of a line (^A is now permitted by Schily-SCCSv6) and NUL characters
  • Binary files are automatically archived as uuencoded text
  • Even binary files get some kind of delta compression
  • Safe against buffer overruns
  • Safe against lock file problems from multi host access via NFS mounted SCCS history files
  • admin -fy allows to selectively enable/disable expansion for each of the %?% SCCS keywords
  • admin -fs# allows to completely disable expansion of keywords after line #

    What are the advantages of Schily SCCS over it's precursor Sun SCCS?

  • Recursive opration over directory trees via sccs -R ...
  • Original date opration via admin -o ... delta -o ... get -o ...
  • Efficient mass entering of initialized files via admin -N ...
  • Schily SCCS has been ported to many platforms and runs nearly anywhere
  • Schily SCCS is safe against Year 2069 as it supports 4 digit year numbers in the history file
  • New SCCS keyword %‍d% for 4 digit year in current date: yyyy/mm/dd
  • New SCCS keyword %‍e% for 4 digit year in date newest applied delta was created: yyyy/mm/dd
  • New SCCS keyword %‍g% for 4 digit year in date newest applied delta was created: mm/dd/yyyy
  • New SCCS keyword %‍h% for 4 digit year in current date: mm/dd/yyyy
  • New SCCS keyword %‍sccs.include.filename% expands file "filename" into file.
  • New SCCS flag "x" to enable Schily type extension (e.g. above new keywords)
  • The "val" program understands directory parameters and expands them
  • The "val" program implements -T to give exact information on why a history file is corrupt
  • New "sccslog" program automatically creates Changelog data from the SCCS history delta comments
  • SCCS v6: A "text" file is any file that contains no NUL characters (^A and no newline at the and of the file is no problem)
  • SCCS v6: The date/time format includes the GMT offset
  • SCCS v6: An extra checksum is available for every release of a file

    Will the upcoming SCCSv6 stay compatible with POSIX and with historic SCCS implementations?

  • All SCCS commands mentioned in the POSIX standard stay 100% POSIX compliant.
  • POSIX intentionally does not standardize the format of the s.file, so SCCSv6 extensions are OK.
  • POSIX non-compliances in the historic source, that SCCS is based on, have been fixed.
  • There are new options in existing commands and new commands to support additional features not mentioned in POSIX.
  • The new SCCSv6 history file format and the format for other files mentioned in POSIX will stay 100% POSIX compliant.
  • When in single file mode (the mode described in POSIX), SCCS is 100% POSIX compliant and in addition 100% downwards compatibile to historic SCCS implementations.
  • When in project mode, SCCS will continue to stay 100% POSIX compliant but needs to prevent historic SCCS implementations (that do not support atomic project updates) from modifying files.
  • The command sccs cvt -V4 file... converts SCCSv6 history files into augmented SCCSv4 history files without losing information.
  • Augmented SCCSv4 history files created from SCCSv6 history files are understood by all historic SCCS implementations (but not by GNU CSSC due to several bugs).
  • SCCSv6 may be able to work in project mode using augmented SCCSv4 history files but then atomic project updates cannot be implemented as we cannot prevent other SCCS implementations (that don't understand global locks) from concurrently updating files
  • The command sccs cvt -V6 file... converts SCCSv4 history files into SCCSv6 history files and adds information if needed and available. Use e.g. "TZ=PST sccs cvt ..." if you know the original files have been created in the bay area.
  • Note that the above statements may not apply to GNU CSSC as this is neither a complete SCCS implementation nor a sufficiently correct SCCS implementaion. GNU CSSC e.g. does not permit more than 32000 deltas in a single history file.

    This is the current TODO list for SCCS:

  • Enhance sccs(1) to allow to copy a tree of SCCS directores to a new destination via sccs copy old-dir new-dir
  • Enhance sccs(1) with a clone command that is expanded to: sccs copy old-dir . ; sccs get .
  • Add a new "release" tag similar to the "mr" tags to the SCCS file headers. To allow tagging parts of a tree to be part of a release snapshot. This will include a special DELETED and UNDELETED tag to allow to mark sccs history files deleted.
  • Allow to retrieve the exact version of a tagged tree (all SID versions for all files that carry <release> as tag.
  • Allow to retrieve the the latest version of all fils from a tagged tree (all SID versions for all files that carry <release> as tag).
  • Add a new project-root understanding and a project-root lock that allows to do things on the whole tree.
  • Use a hacked librmt (from star) to implement remote operations via a ssh (and later web) tunnel.
  • Add a bulk mode to delta(1) similar to the bulk mode implemented for admin(1).

    This is the current state for SCCS transition into project mode support and support for distributed work:

  • sccs(1) added new sub-commands add, commit, init, remove, rename, status.
  • "sccs add" basically works.
  • "sccs init" works.
  • admin(1) supports bulk entering files and everything to support the new "off-tree" mode where history files are in a shadow tree that starts at ".sccs/data" in the project set home directory.

    The current complete TODO file.

    Subscribe to sccs developers mailing list

    Copyright © 2018 J. Schilling Last Change 2017/02/10.