The key is to create a mechanism that enhances data integrity while minimising the alterations required to the way that people work. Roll back and audit mechanisms can be provided using traditional revision control mechanisms such as RCS and SCCS. These do not provide for concurrent access to files, something which CVS does provide. To this end CVS has been chosen as the basis for the system.
An easy first step is to allow files to be edited in place and then commit changes to a CVS repository. While this does not satisfactorily address concurrency it does provide for roll back and a limited audit trail, as well as requiring a minimal amount of change in procedures.
A more far-reaching approach is to have users check out the repository and edit it locally. Changes are then committed and make their way into production using CVS update. This is a more robust solution as CVS provides concurrency control.
As CVS is likely to be used in a networked environment, it is important that security issues are kept in mind. The standard remote access mechanism for CVS is not secure but tools such as ssh enable transactions to be conducted in a secure manner.
The importance of the additional data integrity that this system can provide is highlighted by a phone call I received from a colleague while on the way to Canberra to present this paper for the first time. A configuration file had been truncated and recovery from tape would lose the day's edits. As this file was under CVS control it was a simple matter to recover the most recent revision and put this back into production. While this shows how effective this system can be it also draws attention for the need for accessibility. While the day to day commits required have been made accessible through transparency, recovery mechanisms also need to be made available.
To gain increased reliability it is as important for the knowledge of how to use a system to be freely available as it is to provide redundant data.