October 15, 2001, 1:16 PM — How often does this happen to you?
You add a new Web server to the
network, inserting its IP address in /etc/hosts with plenty
of time to spare before the Demo For Big People. At T-minus one hour
to demo, your browser can't resolve the hostname. Neither can anyone
else's.
Frantic, you check everything before finally coming back to
/etc/hosts. Your change is gone, probably because someone
else edited the file around the same time and overwrote or removed
your edits. You either need some strong configuration control, or a
truly loud warning bell that signals anyone's attempt to modify a
critical file.
Text editors aren't databases -- they don't impose transactional
consistency or concurrency control for multiple updates. This doesn't
affect you one bit if you're the sole system manager at your site, but
as soon as two or more people are chartered to maintain the
environment, you need some sort of control system to serialize and
document configuration changes. The downside is that you'll spend a
non-trivial amount of time deciphering changes made by your peers or
un-doing valid work that conflicts with items on your own task list.
This month, we'll look at the source code control system, or SCCS,
bundled into nearly every Unix operating system and a staple of simple
configuration control.
After explaining the basics of SCCS file
administration, we'll look at the more difficult issues of merging
changes and dealing with files owned by root. Our goal is to reduce the
mystery and annoyance factor of SCCS, and make it a viable tool for
producing an electronic version of your "site book" documenting the
who, what, and why of system-configuration changes.
Rewriting history
SCCS is really a collection of tools that control updates to ASCII
files. You can use SCCS with binary data, which will be converted into
ASCII form using uuencode, but we'll limit this discussion to
ASCII data since that's the source for most configuration files. SCCS
lets you put files under configuration control, check out read-only
copies, acquire write locks for updates, check in and document changes,
print histories, and identify and combine specific updates. Any text
file can be put under SCCS's control, making it useful for managing
plain text documentation and meeting notes.
Before going into the functional details, here's a bit of terminology:
- History files contain the source for the file
under control, as well as a log of all changes made to the file,
information about revision numbers, and access controls. History files
are prefixed with an "s.", and generally live in a subdirectory called
SCCS. - Deltas are specific changes made to a file.
Changing a few characters, adding a line, or removing a line constitute
deltas to a file. Deltas are numbered as minor release numbers from the
main or major release. A particular version of a file, reflecting the
cumulative effect of many deltas, is referred to as an SCCS delta ID,
or SID. Most SCCS commands take an SID as an argument when a specific
version of the file history is needed. - Branches are subdivisions of deltas. While deltas
are used to track the main changes to a file, branches let you create
special-purpose minor variations in a file. Branches may or may not be
merged back together at some point; a typical branch file might be
created when you update your network configuration to host some demo or
loaner machines, and plan to remove those edits in a few days or
weeks. Branches are a convenient form of short-term memory.
When you place a file under SCCS control, SCCS creates the history
file. To change the file, you check it out for editing, and then each
subsequent change to the file is annotated in the history file when
you check the modified version back in. SCCS locks the history file
while one user is editing it to prevent concurrent updates.
Bones of contention
Let's walk through some basic SCCS operations to see how the
components fit together, and then get into the grittier problems that
make SCCS more of a benefit than an added burden. First, you'll need
to have /usr/ccs/bin in your path, since that's where the
SCCS commands live (in SunOS, they're part of /usr/bin).
You can call the individual SCCS commands, or use the sccs
front-end tool to simplify life. We'll use the front-end for
illustrative purposes, but you can also call the SCCS subcommands
directly. Make sure you have an obvious place to store history files,
such as a subdirectory called SCCS. SCCS commands look for
this subdirectory if you don't give an explicit history file location.
