Ask SIPB - May 11, 2004

Want to work on a group project and have everyone edit a common set of files? Heard of RCS and CVS, but don't know what they are? This week, we discuss version control systems and explain how to use RCS.

What is version control and why should I use it?

Version control systems allow groups of people to work on the same set of files. Each person's changes are logged, so that other group members can see who has modified the files and how they were changed. In addition, files can be locked to ensure that group members do not overwrite one another's changes.

The logging of changes also allows changes to be "rolled back" to previously stable versions, so you can modify a working set of files without having to worry about keeping manual backups. Keeping track of different people's modifications to a collaborative piece of work is almost impossible without automatic versioning, so it can be invaluable for any group project, including software development, web design and column writing.

What version control systems are there, and what are the differences between them?

The two most common version control systems in use now are RCS (Revision Control System) and CVS (Concurrent Versions System). RCS is simpler and provides basic tools for version control, and is often used for simple projects such as the Ask SIPB column. CVS is usually used for larger, more complex projects, like software development.

When editing a file stored in RCS, a lock file is created to prevent others from modifying the file at the same time and overwriting the edits made. In CVS, on the other hand, many people can edit a file at the same time, and they can all merge their changes into the file when they finish editing. When conflicting edits are made, they must then decide which edits to keep and which to discard.

How can I use basic RCS?

To start using RCS, make a directory named RCS in each directory you wish to use RCS in.

RCS works by the concept of checking out and checking in files. When you first create a file, you check it in to add it to the RCS controlled system. When you want to edit the file, you can check it out and lock it. This prevents other people from checking out the same file and overwriting any changes you're making. When you're done editing the file, you check it in and unlock it, and only at that point can anyone else check it out to add their own modifications.

To check files in and out, you use the ci (check-in) and co (check-out) commands. For example:

co -l filename
ci -u filename

What other RCS commands can I use?

rlog allows you to view the RCS log and see the list of changes that have been made. For example:
athena% rlog intro.html
RCS file: RCS/intro.html,v
Working file: intro.html
head: 1.3
branch:
locks: strict
access list:
symbolic names:
keyword substitution: kv
total revisions: 3;     selected revisions: 3
description:
----------------------------
revision 1.3
date: 2004/01/04 21:14:02;  author: aerynne;  state: Exp;  lines: +1 -1
Guillotined an erroneous comma.
----------------------------
revision 1.2
date: 2004/01/04 05:03:34;  author: kchen;  state: Exp;  lines: +1 -1
added MIT's
----------------------------
revision 1.1
date: 2003/12/29 04:37:46;  author: kchen;  state: Exp;
Initial revision
=============================================================================
You can see here that the file intro.html has been checked in 3 times, twice by user kchen, and once by user aerynne. The comments sumamrizing the changes that they typed upon checkin are shown as well.

You can also use rcsdiff to see what changed between two versions of the file. The -u option is often useful, as it displays not only the lines that were changed but also the lines surrounding those lines to provide context for the changes.

athena% rcsdiff -r1.1 -r1.2 -u intro.html
===================================================================
RCS file: RCS/intro.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- intro.html  2004/01/02 03:27:57     1.1
+++ intro.html  2004/01/04 05:03:34     1.2
@@ -1,3 +1,3 @@
 Deluged with spam?  In this column, we revisit the topic of spam
 filtering with SpamAssassin, and discuss the new changes made to
-SpamAssassin's configuration.
+MIT's SpamAssassin configuration.
Here, rcsdiff shows the change made between versions 1.1 and 1.2 of the file. The line "SpamAssassin's configuration" was removed, and "MIT's SpamAssassin configuration" was added.

How can I use RCS with Emacs?

After creating the RCS directory as described above, you can check in and check out files in Emacs with the keystrokes C-x v v. When checking in a file after the first time, Emacs will open a buffer prompting you to enter a change comment. After entering your comment, C-c C-c will end your comment and check the file back into RCS.

What information and services might be useful to me over the summer or upon graduating?

Our May 13, 2003 column at http://www.mit.edu/~asksipb/2003columns/2003-05-13-endofterm/ discusses checking e-mail, sending e-mail, forwarding your MIT mail elsewhere, setting up an autoresponder for your mail, deactivation of Athena accounts, alum.mit.edu accounts, and accessing and backing up your Athena account.

Good luck on your final projects and exams! If you have any questions or comments over the summer, or any other time, feel free to e-mail us at sipb@mit.edu.


To ask us a question, send email to sipb@mit.edu. We'll try to answer you quickly, and we can address your question in our next column. You can also stop by our office in W20-557 or call us at x3-7788 if you need help. Copies of each column and pointers to additional information are posted on our website: http://www.mit.edu/~asksipb/