Cover V07, I12
Article
Sidebar 1
Sidebar 2
Table 1

dec98.tar


Sidebar: RCS vs. SCCS

As I recall, some time ago SCCS was more popular than RCS. Today, of the freely available revision systems, it seems RCS and CVS have the lead. (For the purposes of this discussion, CVS may be thought of as a more complex system layered atop RCS. Its additional features would most likely be of little use when maintaining UNIX system configuration files.) Years ago, I switched to RCS. There are two compelling reasons for my migration from SCCS to RCS:

RCS' revision file is named with a suffix (filename,v) rather than a prefix (s.filename), such as SCCS uses. The preference for suffixes is more than cosmetic. Utilities such as make(1) can rely on filename suffixes to select appropriate build rules - so-called "default (suffix) rules". So, SCCS is not easily compatible with all make(1)-based projects - a significant caveat for those who maintain source code. Still, there are some make(1) implementations that have been enhanced to understand SCCS semantics.

RCS stores lock information within the revision file (filename,v) rather than in a separate file (p.filename). RCS has an important advantage here in the UNIX envionment, where links (symbolic or real/"hard" links) are sometimes employed to make a file appear by multiple names or paths. When locking a file with SCCS, a "p." file will be created in the working directory of the user that locked the file. This "p." lock file is only visible within that directory - a major problem if the revision file ("s.") is also linked from another directory. A user in that other directory could also lock the file in question, and both users could edit the file and potentially clobber each other's changes upon "check-in".

For administrative usage of a file revision system, this distinction is doubly important. Popular UNIX implementations, such as Solaris, make heavy use of links to make its configuration files appear in more than one directory (e.g., the file containing the host database is known as /etc/hosts and /etc/inet/hosts). With RCS, you can link the revision file (hosts,v) into both the /etc and /etc/inet directories to accomodate the preferences (and experiences) of the sys admins in your team.

If you ever must convert from SCCS to RCS, there exists a freely available utility called sccs2rcs. It may require a specific minimum version of SCCS (that supplied with HP-UX is not sufficient, for instance), but otherwise it worked well for me.