box.matto.nl
Enjoying Open Source Software

Why you still must use RCS

RCS for revision control

Working with RCS is easy-peasy.

RCS is one of the older revision control systems. Wikipedia states that it was first released in 1982. So, yes, that is old.

And yes. today we have Git, Subversion, Darcs, Fossil, Mercural and whatever. Every new revision control system tries to fix the flaws in the already existing systems, so why would you bother to learn and use RCS?

Well, as with all the tools, you should use the right tool for the right job.

RCS is file based

Most revision control systems are directory based and most revision control systems let you work in a separate work-directory.

RCS is different, RCS is file based and works directly on the local file. This might not be the best solution when dealing with a software project containing subdirectories with code several layers deep. But there is one use-case where RCS excels.

RCS for configuration files

When you want to do a quick fix on a configuration file in f.e. the /etc directory, you don't want to checkout a complete directory somewhere in your $HOME directory, but you want to edit a single file.

But we all know how making a quick fix on a config file can lead to disaster. So you want every change is this kind of files to be documented and you need a quick roll back method. This is why you will love RCS.

Two simple steps to save your bacon

Make this method your standard working method when editing an important file.

First step

Before you touch a single bit, put the file under RCS control.

mkdir -p RCS
ci -u <file-to-edit>
co -l <file-to-edit>

The first line creates a RCS subdirectory. This is not per se necessary, but if you don't, you will end up with ,v files all over the place. When RCS sees there is a RCS subdirectory, it will place its ,v files in that subdirectory, which keeps things nice clean and tidy.

Because the RCS files are in a subdireotory, you have a little bit of extra protection in case you accidentally do a rm in the wrong directory.

The second line (ci -u <file-to-edit>) puts your file under control of RCS and makes it read-only. Yikes

The third line (co -l <file-to-edit>) checks out the file, so make it writable again.

Now you are able to edit it.

Second step

After you are done editing the file, and possibly foobar it, you check in the file again.

ci -u <file-to-edit>

RCS will check it in, so it saves the changes, and make the file read-only again.

Now you can test to see that you didn't screw up, and if every thing works great, fine. If not, you can revert to a previous version and start over again.

Request changelog

With rlog you get a report of the revisions of the file:

rlog <file-to-edit> 

Show the differences with the last checked in version.

During the maintenance of the file, you perhaps would like to see what you have changed since the last revision.

This is very simple:

rcsdiff <file-to-edit> 

This will show you the changes between the current file and the last checked in version.

Seeing changes

To see the diff between two versions, you request them with rcsdiff:

rcsdiff -r1.3 -r1.2 <file-to-edit> 

will show the diff between version 1.3 and version 1.2

To see the contents of an older version, you request co to show it:

co -p1.2 <file-to-edit>

This will show the contents of the <file-to-edit> at revision 1.2.

Revert to older version

You can revert to an older version with co too:

co -r1.2 <file-to-edit>

This will overwrite your current <file-to-edit> with the contents of that file at revision 1.2.

If your file got deleted, you can retrieve it with the checkout command from above:

co -l <file-to-edit>

Using keywords

RCS shares some keywords with CVS. There are quite a number of keywords to use, I mention here only a few.

When you put one or more of the following keywords in your file, they will be expanded with some useful information:

  • $Date$ : The date and hour (UTC) the revision was checked in.
  • $Id$ : Standard header containing the name of the RCS file, the revision number, the date (UTC), the author and the state.
  • $Revision$ : The revision number assigned to the revision.

Practicing

You don't need much preparation to start practice the use of RCS.

First, check that your current system supports RCS, "rcs -v" will show you if it is installed. If not, use your packagemanager to install it. This should be no problem on all Linux distro's, FreeBSD, OpenBSD. RCS can also be installed on Mac OS X and even on ms windows.

Now,in your home-directory create a directory to do some practicing. You can make the RCS subdirectory in one go.

mkdir -p $HOME/rcspractice/RCS

And start practicing.

cd $HOME/rcspractice
vi firsttestfile
ls -l firsttestfile
ci -u firsttestfile
ls -l firsttestfile
ls -l RCS/
co -l firsttestfile
ls -l firsttestfile
vi firsttestfile
ci -u firsttestfile
ls -l firsttestfile
rlog firsttestfile
ls -l RCS/
cat RCS/firsttestfile,v
co -l firsttestfile
echo 'This is the Id: $Id$'  >> firsttestfile
echo 'This is the Date: $Date$'  >> firsttestfile
echo 'This is the Revision: $Revision$'  >> firsttestfile
cat firsttestfile
ci -u firsttestfile
cat firsttestfile

(If you must, you can replace vi by an editor you do know how to use.)

Play around a little more, try to let RCS show older versions of your file, try to revert to an older version. Delete your firsttestfile and do a co -l of it.

Working with RCS is easy-peasy, isn't it?

How this will help you

Files you have put under control of RCS with "ci -u" end up with read-only permissions. This will help you to remember to use the revision control system. (That is why we don't use ci -l).

It is not called revision control system for nothing: you have control over the revisions and can revert to an older version.

All this can be done on location, meaning directly in the directory where the file you want to work on, lives.

Please note, that above we only used the commands ci, co, rlog and rcsdiff. You don't need to learn that much.

So, do yourself a favor, and make it a habit to check files in and out when editing.

BTW, Emacs knows how to deal with RCS.

This page just scratches the possibilities, RCS has a lot more in store. As always, consult your man pages !

Tags:

⇽ Chroot jailed X application testing in Debian We must revive Gopherspace ⇾