Why you still must use RCS
--------------------------
Last edited: $Date: 2017/11/17 09:15:28 $
## 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 seperate 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 ) puts your file under control of RCS and makes
it read-only. Yikes
The third line (co -l ) 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 at revison 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 with the contents of that file at
reverion 1.2.
If your file got deleted, you can retreive 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.
The keywords are placed in $-signs, with no spaces. This document is
under revision control by RCS, therefor, above a space is typed after
the first $-sign. Please ignore this space :)
## Practicing
You don't need much preperation 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 practiceing.
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.)
Just as mentioned above, please remove the space after the first $-sign
in the lines above.
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.
Emacs knows how to deal with RCS, and with a plugin, vim knows it too.
This page just scratches the possibilities, RCS has a lot more in
store. As always, consult your manpages !
