CVS VMS client and RMS file handling. CVS changes file attributes of RMS files. For most files (text, executables / binary) these changes are harmless and are easy dealt with by the tools or the Operating System. Some files however result in unrecoverable damage. It can be a major problem for using CVS on OpenVMS. In our case, FMS files fall it the last category. Even checking those files in with ‘– kb’ option did not eliminate the problem. Main problem CVS isn’t handling the RMS files in the correct way. Handling RMS proper would lead to rewriting some core CVS routines. Most “open source” tools used on the VMS platform have this problem. A number of years ago some people released an adjusted version of ZIP a compressing tool. That specific VMS/AXP ZIP release had a few extra options (/VAX or “–V”) to deal with RMS files. The Zip files are binary sets. CVS file attribute change will not have effect on extracting files. Unzipping will change the RMS file attributes. VMS has a utility “backup” that creates save sets of RMS files similar as TAR on UNIX. The backup utility handles file attributes and the container contents. When restoring a container file attributes are correctly restored. Unfortunately, those backup save set are also RMS files. (fixed record format and fixed record length of 32256 byte. Summary:
Work around: Check-in - Place one or more (all) FMS files in a backup save set - ZIP the backup save set with the RMS zip option - Store the zipped backup save set in CVS (option –kb) ($cvs add -kb <zipped file> Check-out - Retrieve the zipped backup save set from CVS - Unzip the backup save set - Restore the file attributes $set file / attributes=(RFM: FIX, LRL=32256) [backup save set] - Restore the FMS files from the backup save set. Implementation tip: Use a DCL command script to check-in/out and maintain a changelog file |
_______________________________________________ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
