Software configuration management (SCM) with automated Open

Source Version Control Tool RCS (Revision Control System).

When we build computer software, change happens. And because it happens, we need to control
it effectively. Software configuration management (SCM) is a set of activities that are designed
to control change by identifying the software applications that are likely to change, establishing
relationships among them, defining mechanisms for managing different versions of these
applications, controlling changes that are imposed, and auditing and reporting on the changes
that are made.

Code evolves. As a project moves from first-cut prototype to deliverable, it goes through
multiple cycles in which we explore new ground, debug, and then stabilize what we have
accomplished. And this evolution doesn't stop when we first deliver for production. Most
projects will need to be maintained and enhanced past the 1.0 stage, and will be released multiple
times. Tracking all that detail is part of Software configuration management System.

Version control tools help multiple users to make simultaneous changes to a collection of files,
without clobbering each others' work or resulting in version confusion. Version control is
essential for software development. Perhaps the most important problem is reversion. If we make
a change, and discover it's not viable, how can we revert to a code version that is known good? If
reversion is difficult or unreliable, it's hard to risk making changes at all. Almost as important is
change tracking. We know your code has changed; do you know why? It's easy to forget the
reasons for changes and step on them later. If you have collaborators on a project, how do you
know what they have changed while you weren't looking, and who was responsible for each
change? Another issue is bug tracking. To address these problems, we need procedures for
keeping a history of our project, and annotating it with comments that explain the history. Our
projects have more than one developer; we also need mechanisms for making sure developers
don't overwrite each others' versions.

We use a version-control system (VCS), a suite of programs that automates the task of keeping
an annotated history of our project and avoiding modification conflicts.

Most VCSs share the same basic logic. To use one, we start by registering a collection of source
files — that is, telling our VCS to start archive files describing change histories. Thereafter,
when we want to edit one of these files, we have to check out the file — assert an exclusive lock
on it. When we're done, we check in the file, adding our changes to the archive, releasing the
lock, and entering a change comment explaining what we did. Most of the rest of what a VCS
does is convenience: labeling, and reporting features surrounding these basic operations, and
tools which allow us to view differences between versions, or to group a given set of versions of
files as a named release that can be examined or reverted to at any time without losing later
changes.

VCS improves productivity and code quality in many ways, even for small single-developer
projects. They automate away many procedures that are just tedious work. They help a lot in
recovering from mistakes. Some of the most popular and widely acclaimed version control
systems are Source Code Control System (SCCS), Revision Control System (RCS), Concurrent
Version System (CVS), Aegis, PRCS, SVN, Subversion etc.

The superior open-source Version Control System is RCS (Revision Control System). It is
logically similar to SCCS but has a cleaner command interface, and good facilities for grouping
together entire project releases under symbolic names. Some other UNIX/LINUX version-
control systems use it as a back end or underlayer.

RCS is an industry standard collection of tools providing basic file locking and version control
mechanisms. Its strength and durability are indicated by the fact that almost all other version
control tools use RCS as their low-level interface -- RCS is the work-horse engine. RCS is low-
level. It is not client-server. It’s available on all Linux distributions. We use RCS (Revision
Control System) as a method for creating, editing, and using files shared with other users. It is
well suited for single-developer or small-group projects hosted at a single development shop.

When you want to edit the file you should perform the following sequence prior to checking
it out:

1. Run the 'rlog' utility to see if anyone has already checked out the file. If some one has
checked out the file do the following
o if they are editing the file wait for them to check the file back in before
continuing.
o if they forgot to check it back in ask them to check it in before you continue.

An example of the use of 'rlog':

rlog -h filename <Enter>

This will print a short discription of the RCS file including current version and locks.

If you want the full log file (could be quite large):

rlog filename <Enter>

2. Run the 'rcsdiff' utility to insure some one wasn't tampering with the current working
version. If rcsdiff says that there are differences then investigate before continuing. An
example of its use:

rcsdiff filename <Enter>

3. Now that file is ready to be checked out use the 'co' utility. An example of use follows:

co -l filename <Enter>

This command will check out the file named 'filename' and place a lock on it in the RCS
system.

You may now edit the file to your hearts content.

Note: You should check the file in immediately after editing the file. That way you won't
forget why you edited the file (this is important when checking the file.).

4. What should I do if I have to override the RCS lock?

You should only override the RCS lock for the following reasons:

o Some one checked out the file, didn't perform any editing on the file and are not
available to unlock the file.
o Some one edited the file and forgot to check it back in

What you have to consider before overriding RCS locks.

o You have to decide whether or not you are going to ignore the changes or
incorporate the changes in your edit
o If you are going to incorporate the changes perform an rcsdiff and note the
changes before continuing.
o overriding a locked unchanged working file OR overriding a locked changed
working file that you want to DELETE the changes:

rcs -u filename <Enter>

This will unlock the file 'filename'. It will also send an email message to person
who owned the previous lock.

o overridng a locked and changed working file that you want to keep the changes.
a. rcs -u filename <Enter>

This will unlock the file 'filename'. It will also send an email message to
person who owned the previous lock.
 b. ci -l filename <Enter>

This will check in the file 'filename' Enter in the log the following
information:

i. That you overrode the lock by user: ?

ii. The changes that were made by that user and why.

Note: This will also automatically check out the file in your name
so you may perform your changes.

How to check a file into the RCS system. (ci)

1. Checking in an edited file that has previously been setup in the RCS system.

ci -u filename <Enter>

Note: the '-u' option will leave a copy of the file in your working directory. If you
do not use the '-u' option RCS will delete the working file after checking in the
file.

2. Checking in a edited file that has a very long change log message.

ci -m'cat log.txt' -u filename <Enter>

This will check in the file but will get the log information from a previously create text
file named 'log.txt'.

Note: you can use the '-m' option with the '-l' option.

3. Checking in intermediate changes and relocking the file to continue changes. This is an
important tool to use if you are performing extensive changes to a file and you want to
edit you file in stages. In case you botch you changes ... you can recover from you last
RCS checkin.

ci -l filename <Enter>

This will check in the file 'filename' as with 'ci -u'. The only difference is that the file is
immediately checked out and locked after being checked in.

4. Checking in an edited working file and removing the working file.

ci filename <Enter>
 Note: This will delete the working file. This is normally only done when you don't want
any working files hanging around.

How to refresh a currently unlocked working file. (co -u)

co -u filename <Enter>

This will insure the working file is the same as the current saved version in the RCS system.

How to view differences between different RCS versions (rcsdiff)

You can see the differences between different versions of an RCS file.

rcsdiff -r1.5 -r1.3 filename <Enter>

This will compare the two versions of the RCS file 'filename'. It will print the difference list to
your terminal.

The following command will compare the current working file to the most recent RCS saved
version:

rcsdiff filename <Enter>

The following command will compare the current working file to the specific RCS saved
version:

rcsdiff -r1.3 filename <Enter>