Applying RCS and SCCS: From Source Control to Project Controlby Don Bolinger, Tan Bronson
Applying RCS and SCCS tells you how to manage a complex software development project using RCS and SCCS. The book tells you much more than how to use each command; it's organized in terms of increasingly complex management problems, from simple source management, to managing multiple releases, to coordinating teams of developers on a project involving many/i>… See more details below
Applying RCS and SCCS tells you how to manage a complex software development project using RCS and SCCS. The book tells you much more than how to use each command; it's organized in terms of increasingly complex management problems, from simple source management, to managing multiple releases, to coordinating teams of developers on a project involving many files and more than one target platform.Few developers use RCS or SCCS alone; most groups have written their own extensions for working with multiperson, multiplatform, multifile, multirelease projects. Part of this book, therefore, discusses how to design your own tools on top of RCS or SCCS, both covering issues related to "front-ending" in general, and by describing TCCS, one such set of tools (available via FTP). This book also provides an overview of CVS, SPMS, and other project management environments.
Read an Excerpt
Chapter 2: Basics of Source ControlAs we saw in Chapter 1, Source and Project Control, the key to source control is recording successive revisions of a source file so that they can later be recovered. Both SCCS and RCS use a separate file, called an archive file, to hold all the revisions of a given source file. In this chapter we examine more closely how source control works with the archive-file approach. Then, in the next two chapters, we describe the approach using the specific commands in RCS and SCCS.
To begin with, we discuss more thoroughly what kinds of files you should put under source control. We also point out other information that you will need to record to use source control effectively. Then we look in greater detail at the archive file itself and at the actual operations in the source file modification cycle.
Putting Files Under Source Control
Perhaps the most fundamental question to be answered in starting to apply source control to your files is, "What do I need to archive?" The rough answer is simple: only your source files, not files derived from your source files (e.g., object files). A second question might be why you're using source control in the first place. Again, part of the answer seems clear: so you can rebuild a given version of some result, or "product," at a later time. For these answers to be useful, though, we should expand on them a bit. Let's do so.
So What Do I Archive?
You archive source files. A source file is a file that serves as an input to your build or compilation process, that is, one that can't be constructed from other files. A derived file is a file produced by (orduring) your build process. You don't need to save your derived files, as long as you can always reproduce them from your sources.
A c file, of course, is a source file, while the corresponding o file is a derived file. Similarly, a spooler configuration file is a source file, both when you get it off the tape and after you've modified it for your own installation. The installed spooling system, however, is a set of derived files. If you're a writer, a troff or TeX file would be your source file, while a PostScript file would be your derived file. Thus source files can be developed wholly by you or your co-workers, or they can be bought or otherwise obtained from outside your own group. Either kind of file is a candidate to go under source control.
More important than the file's type is whether the file has been modified since you received it, or whether it is likely to be modified in the future. Files that you keep for read-only access probably don't need to be under source control. The files that you want control over are the ones that you actively modify, which we will call dynamic source files. So a more precise statement of what to archive would be: only your dynamic source files.
Static source files (that is, ones that you treat as read-only) need not be under source control. However, you do need to know where they're kept so that you can always put your hands on the static files that were used in a specific context. The obvious example for software development would be compile-time files provided for a given execution environment like the C-language header files you find on POSIX-compliant systems.
When we speak of "archiving," of course, we mean storing revisions of a source file within an archive file. We don't mean the usual sense of archiving, which involves storing disk contents on some backup medium, such as tape. Needless to say, you should keep adequate backups of all files on your system-but that's not what we're discussing here.
Ensuring You Can Reconstruct Derived Files
As you squirrel away revisions of your sources for future reference, bear in mind that you will usually need more information than the source files themselves to reconstruct the derived files. You may also want to know several things about the tools and environment you used to build derived files, such as:
- What compiler you used
- What header files you compiled with
- What object-file libraries you linked against
- What shared library images were used with your derived files at runtime
Similarly, if your source files can be configured and built in different ways (as with C-language preprocessor definitions), you need some way of recalling exactly what configuration options you used in your last build. The configuration options that are required to produce a given derived file are often recorded in a Makefile, for use by the make(1) utility. Make is a powerful adjunct to both source and project control, and we will present detailed suggestions for using it in Chapter 19, Makefile Support for Projects.
Recording what version of tools and support files you used is really a question of project control, which we'll address in depth in Chapter 17, Contents of a Project. For now, let's just say that you can associate your tools and support files (or links to them) with each project tree.
The important point is that simply saving the right revisions of your sources isn't enough to let you reconstruct the derived files that you originally built. You may also need to save and reuse the same configuration options as you did the first time through, and you may also need to use the same tools and support files. About the only time you can afford to ignore these issues is when you use only one version of a single compilation environment and when you compile and distribute your source files configured in only one way.
Even in this case you should ask yourself whether you're really never going to change anything. If you don't record all of the information you need to rebuild a given set of derived files, you make it hard or even impossible to maintain them in a controlled way. In fixing bugs, you need to start with a known source file revision, build a derived file from it to verify the bug report, then make your fix and rebuild again. If in this process you can't verify your starting point, then you can't be sure of where you wind up either.
Before we launch into a detailed description of how to interact with an archive file, it may be useful to point out a few characteristics of such files that are common to RCS and SCCS. We also introduce the terminology that you'll see throughout the book when we talk about such files.
Unfortunately for the reader who wants to compare the two, RCS and SCCS use different terms for equivalent objects and operations. To streamline our presentation, we've adopted a single set of terms (closely tracking the ones used by RCS) throughout the book, whether we're discussing source control in the abstract or presenting one of the two systems.
As you've seen already, we refer to the file containing multiple revisions of a source file as an archive file, and each archived version of a source file is called a revision. Associated with each revision of an archived file is a number that,...
Meet the Author
Don Bolinger is a software engineer in the Research Institute of the Open Software Foundation, where he works with the Mach microkernel and serverized UNIX systems. He has labored on, in, and under various UNIX-like environments for around 15 years. His first exposure to project control came long ago via an m4-based front-end to make, which demonstrated how easy and useful (not to say necessary) it is to write such extensions under UNIX. Subsequent work on many other tools taught him the value of discipline and a healthy respect for prior art, both of which he hopes this book manages to pass along. Don got his B.A. in English from Yale University, and finds natural languages just as engaging as the programming kind. He enjoys French history, culture, and wine (not necessarily in that order).
Tan Bronson is currently director of software engineering at Hill Arts & Entertain ment, in Guilford, Connnecticut, where he works on providing ticketing to the performing arts and related industries. Tan's been working on or around UNIX systems since his exposure to Version 6 UNIX 15 years ago. On Version 6 UNIX he started writing drivers, and over the years worked his way "up to" applications. His first exposure to source code control was a homebrew system that built software that was cross-compiled on a Vax for a 68010 UNIX box, and ran on the same Vax. It quickly grew to a more "general purpose" collection of tools. Over the years he's tried to take advantage of all the good ideas he's encountered building and controlling projects, and help other people have better control over the software project they need to release and maintain. Tan got his B.S. in electrical engineering from the University of Maine at Orono, and spends his spare time with his family and working on a variety of home construction projects. (Unfortunately, RCS doesn't apply to these!)
and post it to your social network
Most Helpful Customer Reviews
See all customer reviews >