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

• Email
• Print
• Share
  • Slashdot
  • Digg
  • Stumble
  • Reddit
  • Newsvine