What's GNU?
What is RCS? RCS is the Revision Control System. Its job is to manage the process of revising and updating files. It can and should be used for program text and documentation, as well as for any other files that are revised on a frequent basis. RCS allows you to retrieve earlier versions of files, while keeping a log of what changes were made, who made them, and why. RCS makes it easy to compare any two versions of a file, and provides a mechanism for merging changes from two different development “branches” of a source file.
RCS was originally written by Dr. Walter F. Tichy, at Purdue University. Beginning in 1983, it received wide-spread use in the Unix community with its release as part of the User Contributed Software in 4.2BSD. It was described in an article in “Software—Practice And Experience” in July 1985.
RCS provides a safety net for the software developer. When developing, fixing, and improving a program, changes are inevitable. By saving a stable version of your file in RCS, you can later return to a known state if a set of changes does not work out.
If more than one person is working on the same file, RCS allows you to “lock” a file, so that only one person will be allowed to make changes. Other people can still use the file, e.g., for compiling.
Besides keeping track of what changes were made to a file, RCS tracks who made the change and when. RCS also files a log message describing the change. This makes it easy to figure out who broke the program when the fatal bug is finally isolated.
The user interface is intentionally quite simple, consisting primarily of two commands, ci and co. To start with, make a directory to hold the program and cd into it. Then make a directory named RCS. Although not required, this is the cleanest way to do it; all RCS files will be kept in the RCS subdirectory. We'll also create the first version of the program.
$ mkdir hello
$ cd hello
$ mkdir RCS
$ cat > hello.c # editors are for wimps! :-)
#include <stdio.h>
int main(void)
{
printf("hello, world\n");
}
^D
$ ls -l hello.c
-rw-r--r-- 1 arnold 66 Nov 5 22:33 hello.c
We now have a C source file that is ready to go. When compiled and run, it prints the well-known, friendly greeting beloved by C programmers the world over.
After making sure it compiles, the first thing to do is “check in” the program with RCS. This is accomplished with ci.
$ ci hello.c RCS/hello.c,v <-- hello.c enter description, terminated with single `.' or end of file: NOTE: This is NOT the log message! > world famous C program that prints a friendly message. > . initial revision: 1.1 done $ ls RCS
The first time a file is checked in, RCS wants a description of just what the file is. It reminds us that this is not the log message, thus, something like “initial revision” would be inappropriate here. The > is the prompt for information. Also note that the original file is removed. RCS has the file safely stored in the RCS file hello.c,v in the RCS directory.
Well, a file that we can't compile isn't of much use, so the next thing to do is get a copy so that we can actually compile the program and use it. This is done with co, which stands for “check out”.
$ co hello.c RCS/hello.c,v -> hello.c revision 1.1 done $ ls -l hello.c -r--r--r-- 1 arnold 66 Nov 5 22:43 hello.c $ gcc hello.c -O -o hello; ./hello hello, world
Note that the file is returned to us, but with read-only permissions. We are thus allowed to use the file, but not change it. In normal use, for instance, to build a whole source tree to install software, you would check out the files read-only, compile the programs, and then remove the source files.
What about when you want to change a file? Programs do evolve, so how do you get to the next revision? The first thing to do is to check out the file, but with a lock on the file. The lock says that you, and only you, are allowed to check in a new revision of the file. This is necessary if more than one person will be working with the source file, so that two people don't trash each other's work.
$ co -l hello.c RCS/hello.c,v -> hello.c revision 1.1 (locked) done $ ls -l hello.c -rw-r--r-- 1 arnold 66 Nov 5 22:51 hello.c
This checks out the file, and locks it. Note that the permissions now allow writing to the file. We can edit the file, and make our changes to it.
$ sam hello.c # a nifty editor,
# watch for a future column on it.
$ cat hello.c
#include <stdio.h>
#include <string.h>
int main(int argc, char **argv)
{
if (argc > 1 && strcmp(argv[1], "-advice") == 0) {
printf("Don't Panic!\n");
exit(42);
}
printf("hello, world\n");
exit(0);
}
$ gcc -O hello.c -o hello
$ ./hello -advice
Don't Panic!
$ ./hello
hello, world
Our program now has a new option, -advice, that prints a friendly piece of advice and exits with a well known, special value. The default behavior remains unchanged, except that exit is now used for the normal case, as well.
We can now check in the new version to RCS. Assuming that we will want to do further work on the file, ci also allows us to use the -l option. With this option, ci will perform the check-in and automatically do a co -l for us, so that we can continue to work on the file.
$ ci -l hello.c RCS/hello.c,v <- hello.c new revision: 1.2; previous revision: 1.1 enter log message, terminated with single `.' or end of file: > Added -advice option, and made regular case use exit. > . done $ ls -l hello.c -rw-r--r-- 1 arnold 208 Nov 5 22:54 hello.c
Here we see where the log message is entered. Log messages should be relatively brief, describing what was changed and why. In a commercial environment, you might enter the bug number associated with a particular fix into the log, as well. We also see that the file is still available for further editing (permissions -rw-r--r--).
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Sponsored by AMD
If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.
Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.
Sponsored by ActiveState
| Non-Linux FOSS: libnotify, OS X Style | Jun 18, 2013 |
| Containers—Not Virtual Machines—Are the Future Cloud | Jun 17, 2013 |
| Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer | Jun 12, 2013 |
| Weechat, Irssi's Little Brother | Jun 11, 2013 |
| One Tail Just Isn't Enough | Jun 07, 2013 |
| Introduction to MapReduce with Hadoop on Linux | Jun 05, 2013 |
- Containers—Not Virtual Machines—Are the Future Cloud
- Non-Linux FOSS: libnotify, OS X Style
- Linux Systems Administrator
- Validate an E-Mail Address with PHP, the Right Way
- Lock-Free Multi-Producer Multi-Consumer Queue on Ring Buffer
- Senior Perl Developer
- Technical Support Rep
- UX Designer
- Introduction to MapReduce with Hadoop on Linux
- RSS Feeds
Featured Jobs
| Linux Systems Administrator | Houston and Austin, Texas | Host Gator |
| Senior Perl Developer | Austin, Texas | Host Gator |
| Technical Support Rep | Houston and Austin, Texas | Host Gator |
| UX Designer | Austin, Texas | Host Gator |
| Web & UI Developer (JavaScript & j Query) | Austin, Texas | Host Gator |
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?




47 min 57 sec ago
1 hour 13 min ago
3 hours 42 min ago
4 hours 15 min ago
4 hours 16 min ago
4 hours 17 min ago
4 hours 19 min ago
4 hours 20 min ago
4 hours 22 min ago
4 hours 23 min ago