Applying RCS and SCCS: From Source Control to Project Control
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...
Search in google:
Now there's a book that gives you some help managing your project's source files. Applying RCS and SCCS is a thorough introduction to the two most popular source control systems under UNIX. The authors of this book take you from basic source control of a single file, through working with multiple releases of a software project, to coordinating teams of developers on a project involving many files and more than one target platform. The authors go well beyond lists of commands and command options: they help you define the problem you're really trying to solve, and then they show you how to solve it. This book also presents TCCS, a representative "front-end" to RCS and SCCS that addresses problems RCS and SCCS can't handle alone, such as managing groups of files, developing for multiple platforms, and linking public and private development areas. If you're a programmer or a software project manager, this book should be required reading. Booknews An introduction to two popular source control systems under UNIX, covering basic source control of a single file through working with multiple releases of a software project and coordinating teams of developers on a project involving many files and target platforms. Also covers project administration, using work areas, and TCCS, a representative front-end to RCS and SCCS. Includes eight reference appendices. For programmers and software project managers. Annotation c. Book News, Inc., Portland, OR (booknews.com)
Chapter 2: Basics of Source Control\ As 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.\ Some Conventions\ 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.\ Nomenclature\ 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,...
Preface Chapter 1. Source and Project Control Chapter 2. The Basics of Source Control Chapter 3. Basic Source Control Using RCS Chapter 4. Basic Source Control Using SCCS Chapter 5. Extending Source Control to Multiple Releases Chapter 6. Applying RCS to Multiple Releases Chapter 7. Applying SCCS to Multiple Releases Chapter 8. Managing the Mechanics of Releases Chapter 9. Release Mechanics in RCS Chapter 10. Release Mechanics in SCCS Chapter 11. Extending Source Control to Multiple Developers Chapter 12. Applying RCS to Multiple Developers Chapter 13. Applying SCCS to Multiple Developers Chapter 14. Creating Front-Ends for RCS or SCCS Chapter 15. Going Further with Source Control Chapter 16. Moving from Source Control to Project Control Chapter 17. Contents of a Project Chapter 18. Administering a Project Chapter 19. Makefile Support for Projects Chapter 20. Using Work Areas Chapter 21. Extensions for Cross-Development Chapter 22. Structuring the Build Process Chapter 23. Existing Layers on RCS and SCCS Appendix A. RCS Quick Reference Appendix B. SCCS Quick Reference Appendix C. RCS and SCCS Compared Appendix D. RCS Details in Depth Appendix E. SCCS Details in Depth Appendix F. RCS/SCCS Internals Appendix G. Changes in RCS Version 5.7 Appendix H. References Index
\ BooknewsAn introduction to two popular source control systems under UNIX, covering basic source control of a single file through working with multiple releases of a software project and coordinating teams of developers on a project involving many files and target platforms. Also covers project administration, using work areas, and TCCS, a representative front-end to RCS and SCCS. Includes eight reference appendices. For programmers and software project managers. Annotation c. Book News, Inc., Portland, OR (booknews.com)\ \
![Microsoft Office Project 2007 Step by Step [With CDROM]](/application/data/covers/30/57/9780735623057.jpg "Microsoft Office Project 2007 Step by Step [With CDROM]")
