SCCS 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.
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.