 |  |
| |
The Revision Control System (RCS) is a straightforward, file-based source-control system. It allows you to keep track of multiple snapshots or revisions of a file, so that you can back up to any previous version. It also allows you to note particular versions, so that you can do things such as reproduce the version of a file that you gave to someone else or released as part of a software release. Of course, it's useful for more than just software development; any time you want to change a file or set of files, revision control can be useful. To place a file under revision control using RCS:
% ci filename
The ci (checkin) program will prompt you for a short description of the file and commit your changes. It will by default also delete the working copy; if you want to keep a read-only copy, use the -u (unlocked) option.
To then get a working copy of the file from scratch:
% co filename % co -l filename
The co (checkout) command will get a read-only copy of the file from RCS. If you want to edit the file, use the co -l command (the option is a lowercase L and stands for lock). While you have the file checked out and locked, no one else can edit it. When you're done, return the file to RCS (check it in) using ci again. If you use the -l option to ci, it checks in your changes and checks out a new working copy, as if you did co -l again. When you check in the file, ci asks for a brief description of your changes. These can be very useful, later, to learn the history of revisions and to find a particular revision you might want to recover; the command rlog filename gives all of the stored change descriptions.
If you create a subdirectory called RCS in the directory where you keep the code or other text files you want to protect, the RCS files will be put there for you, rather than cluttering up your main directory.
It's a good idea (but not required) to add the characters $Id $ somewhere in the file you want to place under RCS. Put this in a comment field. That is, use /* $Id $ */ in a C program and # $Id $ in a shell or Perl script. RCS will substitute the revision of the file and other useful information wherever you put $Id: ch39_05.htm,v 1.3 2002/11/05 20:21:01 ellie Exp ellie $ any time you check the file out; this allows you to look at a file later and know what revision it was.
If you check out a file for editing and later on decide you didn't want to change it, unlock the file using:
% rcs -u filename % rm filename
If you want a list of all files currently checked out, use:
% rlog -L -R RCS/*
(If you don't use RCS often, you may want to store those command lines in aliases or shell functions (Section 29.1) with names like Checkout, Checkedout, and so on.) That's all there is to it!
If you are not using RCS or CVS, you should. They are an easy, ongoing way to protect yourself and do not require dozens of tapes. It is much easier just to type:
% co -r1.12 filename
than it is to try to restore that version from backup tapes after you've deleted it. With one command, version 1.12 is restored. If it's not the right one, restore the version before or after the one you just grabbed. (If you would just like to see the file rather than get a copy, you can add the -p option to send the file to standard output. Don't forget to pipe the co -p output to less or something similar, unless it is really short.)
If you are worried that you are keeping 12 versions of the file on the disk and that this will use up a lot of disk space, don't be. RCS stores the differences between versions, not 12 separate copies of the file. It recovers earlier versions of the file on request by starting from a known point and applying patches, rather than just keeping every single revision.
Suppose you delete a file by accident. If the file is just checked out with co, it will be retrieved and marked read-only, so trying to delete the file will cause rm to ask you for confirmation. If you do delete it, you can just recover it with another co command. Suppose, however, you checked out a file with co -l, because you planned to change it. If this file gets deleted accidentally, you would lose the most recent changes. This is why you should check your files back into RCS frequently -- several times a day or even more. Checking in a version whenever you make significant changes to the file, or if you make changes that would be difficult to remember, is the best insurance. Making hundreds of changes to a file without checking it back into the system is just begging for trouble.
This brief overview left out a lot of features and helpful information. For example, RCS can:
Merge two or more peoples' work into one with rcsmerge and co -j.
Build a tree of revisions with multiple branches and sub-branches. This lets you make and store multiple independent revisions.
Assign an arbitrary "state" to certain revisions -- for example, alpha, released, stable.
Name some or all revisions and refer to revisions by name instead of number. This is particularly good for naming files that went into a release.
Keep a list of users who are allowed to manipulate a particular RCS file.
To find out more, see the RCS manual pages. rcsintro(1) gives a more complete overview; manpages like ci(1) have details on the many other useful features. Finally, O'Reilly & Associates' Applying RCS and SCCS is packed with tips and techniques for using revision control in group projects (where you'll need it even more). Section 13.7 and Section 39.6 explain tools for searching RCS files.
If you're doing a larger project, take a look at Section 39.7, which discusses CVS. CVS is much better at large project coordination and provides a whole suite of useful features beyond the simple source control RCS provides.
--DJPH and BB
|  | |
| 39.4. Managing and Sharing Files with RCS and CVS |  | 39.6. List RCS Revision Numbers with rcsrevs |
Copyright © 2003 O'Reilly & Associates. All rights reserved.