The GNU Revision Control System (RCS) is as indispensable a tool for programming language source code files as it is for files placed on the World Wide Web. The following covers two likely roadblocks when using RCS with web files, and how to get avoid them.
Note: How to provide RCS over the web, or prove RCS as a backend of some web application is not discussed below.
The two likely difficulties that arise when using RCS to maintain versions of web include:
Both of the mentioned problems should be seen as consequence of design decisions made for RCS. These are not typical problems that most people using RCS should know better to avoid. Instead, RCS's design was carefully crafted to succeed in a software developer environment. For instance, compiling source files was an assumed task.
RCS was specifically written for individuals who work with compilers. This includes the computer programmer and scientist who write source code in a programming language, and the academics and technical writers who write documentation in source files (which get processed by some formatting and typesetting processor). After a compiler (programming language or typesetting) produces the output (program executable or printable document) there is no need to keep a full copy of the file around. This makes it easy for users by minimizing the number of files they have to look at in a directory. At the time RCS's development, disk and tape storage space was both limited and financially expensive. Being able to delete unnecessary files was therefore a benefit. Furthermore, outputting the list of files in a large directory containing many files would take seconds, as opposed to today's fractions of a second.
Things have changed. Computer storage space is larger and cheaper. Computer performance is much faster. Tasks are becoming more instantaneous rather than requiring intermediate compiling stages. Documents are "live" and dynamic rather than static. The world wide web is an open publishing system and not the sheltered work of university or industry. This brings us to file permissions.
There really is no historical explanation why file permissions create problems when using RCS with web files. Web server software installed on systems that enforce permissions to files (originating and found on most Unix-flavored operating systems) also enforced by the web server. Improper file permissions are usually just oversights made by the user. An oversight that can happen to users with all web files, regardless if they are being used with RCS or not.
As mentioned above, files are deleted upon check in (RCS's
ci command) to save disk space, under the assumption the
files are no longer needed for compilation and are available from the file's RCS file upon request by issue of being checked out (RCS's co command). On the web, files are never
compiled and the current version of a file needs to always be
available, not just available on request.
A version of a file in its entirety can persist beyond check-in by simply
using the unlock (-u) command-line option. This option demands that the file be checked-out as "unlocked" after being checked-in. So rather than doing:
ci index.html
to check in your latest revisions to the file index.html, do
ci -u index.html
This checks in the file, but keeps the file from being deleted and makes it available unlocked (not editable). Unlocked because this is the opposite of checking-in a revision and keeping the file from being deleted but locked for further editing.
Consider if you made the initial check-in of a web page file but
then later noticed that you goofed on the permissions, and that the
working file needs to be made available to the web server as
world-readable, or perhaps world-executable in the case of a CGI
script. Just change the RCS version file (,v) to the
permissions you need. Files checked-out of RCS are given he same
permissions as the RCS version file.
Applying the permissions to the working file will not fix the problem. RCS ignores the permissions of a check-in file, furthermore file permissions are not represented in the versions of an RCS file. File permissions are not something that is recorded or considered about each version submitted. It does respect them, though. It's left as an administrative task.
I learned this last one the hard way. I assumed file permissions were somehow part of the RCS version file, or perhaps a command line option. I was too scared to play with permissions on the RCS file, and I assumed there would be a better way to do things then going around RCS and doing it manually. I also assumed one had to check-in a file with the desired permissions.
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".