by <No I'm not the Author of RCS> (Aaron Hawley).
Currently, not much is happening with RCS. This is the situation. There are likely a generous number of people continuing to to use RCS and an even greater of files and file revisions stored in the RCS format just sitting around. A popular version control system, CVS, uses the RCS format and there are other parsers of the RCS file format (MIT/GNU Scheme comes with one). In summary, RCS is widely adopted, but as a software package is never improved. This makes for a unique and interesting scenario.
In terms of development, there is relatively nothing happening with the RCS package. The current version is 5.7, released in 1995. RCS is a GNU package and is maintained by Purdue University. The only recent likeness to development of the package has been the porting of the software package to other computer platforms and the distribution of binaries for these platforms (Note: In early 2006, rumor has it that the GNU project is interested in packaging a new release sometime soon. Stay tuned.).
RCS, like all software, is susceptible to bit rot: the tendency for unused software to fail in seemingly mysterious ways (Eric S. Raymond. Jargon File. On Internet: <http://catb.org/~esr/jargon/>. Downloaded July 29, 2004. Last modified December 29, 2004). On the contrary, RCS resides on decades of development. It was actively developed by the original author and designer of RCS, Walter Tichy, who spent time to develop RCS as a stable software application. Eventually, RCS was released under the GNU General Public License and then passed on to the Free Software Foundation. Currently, GNU RCS is being maintained by Purdue University, where Walter Tichy used to work. With its stablility, many have found it unnecessary to continue adding features to the software package. Intead, the focus is on maintaining backwards compatibility, and adding new version control features only to newer version control software packages.
Active development of GNU RCS by the free software community is essentially non-existent. This is the consequence of:
Quickly: Choose which project, which version, which release and which revision of version control system you would like. (end humor)
Software support for RCS is available, in the same way all free software is, by electronic communication over the Internet. Information on RCS support is collected at:
Many people have moved on from RCS to other version control systems. Any major changes or improvements probably cannot be made to RCS since it is such an industry standard; there are many other systems that build on top of the RCS command interface and file formats and rely heavily on its predictable, historical behavior.
This author believes RCS could use continued development. And this goes beyond even just fixing bugs. Granted, RCS has weaknesses including:
These design shortcomings are arguably inconsequential for providing individuals who are deterred from related systems with too may features, and thus are not leveraging any version control system in their current work. Traditional software developers continue to drop one versioning system for the next, moving from one feature-rich, over-engineered solution to the next iteration. Many users who could benefit from version control but don't need these powerful features demanded by software developers, and often are turned away by their confusion.
For these reasons, future RCS development should occur. Development pursuing the following tasks (in no particular order) could prolong RCS's life and support the users left behind by other version control systems.
This could all be done with RCS in its current form. The only thing keeping this from happening are willing individuals to support active development.
End proselytizing language.
Fortunately, if you're using RCS, or have old RCS files lying around, most newer versioning systems already support or promise RCS compatability with their own format. So don't fret; you're in good company no matter what.
Interestingly, people are still using SCCS (a really old "Source Code Control System" available on commercial Unix systems). So much so, that the free software movement is working hard to make sure it has its own (see CSSC). So if you felt like a dinosaur for using RCS, just think about those people using the SCCS system.
Why not! RCS has weaknesses that other software packages overcome, but will you ever truly use the advanced features of an improved versioning system? Won't those features just turn you off from versioning systems? If RCS doesn't support the needs of your work or you are critical of RCS's weakness, than you should investigate those other systems. But for those that aren't developing software for NASA, why not use RCS?
RCS has a small and specific task, and it accomplishes it just fine. If you are backing up files with new extensions like ".bak", ".bkp", ".backup", ".old", or ".copy", then in the words of the social philosopher Susan Powter "Stop the Insanity!". Seriously, it's a waste of space, and learning how to use a versioning system is easier then spending the time figuring out which backup copy you want to keep.
End promotional language
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, with the Front-Cover Text being "A free book about free software", and Back-Cover Texts being "You have freedom to copy and modify this book".