| Department of Computing | Imperial College London |
| Version Control: RCS, CVS and Subversion | |
We strongly recommend that you familiarise yourself with one or more version control systems and use them routinely for your work. Version Control Systems are an essential part of a professional computer programmer's skill set.
At their simplest, version control systems allow you to take backups of all your important files. Really, as a professional programmer, you should aim to never lose an important file. If you do, then you've been, frankly, stupid.
However, version control systems give you much much more than a mere anti-stupidity defence. They are a core technology for allowing programming in the large, allowing large teams of developers to cooperatively design and build large projects. At the largest scale, version control systems can also help to tackle configuration management, one of the hardest enduring practical problems in Computer Science.
RCS is a very simple version control system which manages multiple revisions of text files. It is suitable for small projects with one or several developers where, essentially, only a single "working copy" of the project need exist, and developers make small atomic changes essnetially one at a time.
It is useful for text that is revised frequently, for example programs, documentation, etc. RCS maintains a complete history of changes and resolves access conflicts.
CVS is a more complex version control system which works on a whole directory tree of files forming a single project, and allows a large number of geographically separate developers to work on larger projects. The basic difference is that each developer works on a separate and independent local "working copy" of the whole suite of files in a project, and periodically checks their changes back in, and resynchronizes their working copy with the master copy.
See the manual page or ximbiot.com/cvs/wiki/ and cvsbook.red-bean.com for further information.
A set of DoC-specific instructions for using CVS are in preparation; please email help@doc if you need a copy.
Subversion is a more recent replacement for CVS, that has roughly the same set of concepts, but which frankly works better.
A set of DoC-specific instructions for using Subversion are in preparation; please email help@doc if you need a copy.
Very basic use of RCS is simple. First, in each directory where you have files you want to start version controlling, create an RCS directory to store the version history files in:
mkdir RCSThen you only need to know two commands:
ci -u FILE co -l FILE
In order to submit a file (eg. First.t) to RCS for the first time, you "check in" the file:
ci -u First.t
This command creates a file RCS/First.t,v and stores First.t into it as revision 1.1. A ,v file is a RCS version file ("v" stands for "versions"), which stores a complete history of all the changes made to that file - not just information about who changed what when, but the actual content changes involved. This means that, using more complex RCS commands, you really can use the version history to recreate any past version of the file! Amazingly, given all the information that is stored in a ,v file, it is typically only 2-3 times the size of the working file.
First.t becomes a readonly ("checked out unlocked") copy which should not be directly edited (read on).
When you want to start editing First.t you type the check out locked command:
co -l First.t
This command extracts the latest revision from First.t,v and writes it into First.t. Note the -l option which locks the file ready for you to edit - i.e. makes the file writable by you.
You can now edit First.t to your heart's content, safe in the knowledge that noone else may edit it while you are. When you have finished one small atomic set of changes, and have checked that your changes work (eg. by recompiling the code and testing it), you then check it back in by invoking:
ci -u First.t
ci submits your altered copy of the file as a new version, incrementing the revision number (1.1->1.2->1.3->..), computing the set of alterations you made, and again leaves you with a readonly ("unlocked") copy of First.t for you to use.
You can also retrieve any previous revision and edit it. For example, if you wanted the second revision of your program, you could do so by typing:
co -lr2 First.tRCS offers many more features for good project management. A full description is beyond the scope of this introductory document.
See the following manual pages for further information:
rcsintro rcs ci co rcsdiff rcsmerge rlog ident
| © CSG / Nov 2006 |