39.5. RCS Basics
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:
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
![Previous](../gifs/txtpreva.gif) | ![Home](../gifs/txthome.gif) | ![Next](../gifs/txtnexta.gif) | 39.4. Managing and Sharing Files with RCS and CVS | ![Book Index](../gifs/index.gif) | 39.6. List RCS Revision Numbers with rcsrevs |
Copyright © 2003 O'Reilly & Associates. All rights reserved.
|