Contents
Basic Operations
Command Does what
co -l file checks-out the most recently-committed copy of file (with a lock)
co -r#.# file checks-out revision #.# of file
ci -u file checks-in file and removes existing lock (also prompts for a commit message if changes were made)
rcsdiff file shows diff existing between the current copy of file and the most recently-committed copy of file
rcsdiff -r#.# -r#.# file shows diff between revision #.# and #.# (rcsdiff -r1.19 -r1.25 file)
rlog -b file shows the commit logs for changes of file
Useful Information
- RCS trusts regular UNIX permissions for 'co' and 'ci' to determine who may modify a file.
- This most matters on the parent directory - as when a file is checked out - the original file is removed (unlinked) and the file is created as the current-user from the file,v information. (Look at the 'stat' output (for inodes) on a file, then co the file and inspect again.)
- To allow a group to all make changes to a set of files, use regular unix groups (with g+rwx on the parent directory) to allow modifications.
- If the directory 'RCS/' exists when initializing/checking out/checking in a file - that directory is used to hold version/locking files.
- Thus, the RCS/ directory should have the same permissions as its own parent directory (if dpocock:projecta 0775 /data/project/, then /data/project/RCS should also be dpocock:projecta 0775)
- RCS uses access lists to further limit user modifications
- If no access list has been defined, any user with system-level unix-permissions may modify the file
- Set with 'rcs -ausernamefile', repeat for each username that should be able to modify the file.
- The user still must have the unix-permissions to edit the file.
- The access list may be seen in the head of a file,v information like: access\n\tusername;
Hacky History-Searching
I recently had an issue at work where I needed to find when a particular DNS entry was added/removed from the zone file. This was on an older system and was using RCS. A System Administrator had re-added the entry in revision 3.9614. We were currently on revision 3.9616. I needed to know when/why it was removed.
To not bother production, I copied my file & file,v to /tmp/. Then I confirm when it was added back by manually looping through each revision and checking it out until the entry was not present:
NUM=9616 # current revision
while true; do co -r3.${NUM} db.zone 2> /dev/null; grep missinghostname db.zone > /dev/null || break; NUM=$(( $NUM - 1 )); done
echo "missinghostname NOT found on revision 3.${NUM}"
As expected, this returns "Not found on revision 3.9613". This was the revision before the Administrator re-added it, so this makes sense.
Next, I did a very similar loop - except checking for where the host is present again - to find when it still existed:
NUM=9613
while true; do co -r3.${NUM} db.zone 2> /dev/null; grep missinghostname db.zone > /dev/null && break; NUM=$(( $NUM - 1 )); done
echo "missinghostname Found on revision 3.${NUM}"
This returns "Found on revision 3.8723". That means it was removed in revision 3.8724. I can then use rlog -r3.824 db.zone to find the commit/reasoning/date of removal.
