RCS. The classic. All the documentation you will ever need is in the man pages. Well that and some context for how to use it. RCS creates revision files in place. So if you change /etc/dhcpd.conf, it will create /etc/dhcpd.conf,v. This is a very useful setup when controlling local files in arbitrary locations - like most of /etc on most of your servers. There are a few caveats to keep in mind:
- RCS will put revision files (the ,v files) in an RCS folder if present
- The default behaviour is to remove a file from its current path on check-in
- If there is no RCS folder (e.g. /etc/RCS), create it first
- mkdir -m 700 ./RCS
- Assuming your working folder is where the file in question is, this will create an RCS folder and protect it from other users (typically non-root)
- If a file doesn't exist in RCS, check it in first
- ci -u dhcpd.conf && co -l dhcpd.conf
- ci is short for "check-in", unlike SVN or CVS, "ci" is the command and not an argument to "rcs"
- The -u "unlocks" the file leaving it in place (so dhcpd can read it)
- co is "check-out" and -l "locks" the file for editing
- I always leave files checked out to capture changes by other users or by the system (like rpm)
- If the file does exist in RCS, check for any un-committed changes
- rcsdiff dhcpd.conf
- This does a diff against the last checked-in version by default but you can specify a version if you want to compare against earlier changes
- Check-in any un-committed changes or find the person who made the changes and make them do it
- The file should always be left checked-out (per above comment), otherwise check it out
- Make changes
- Check-in changes, and check-out the file for the next user
- ci -u dhcpd.conf && co -l dhcpd.conf
- Give a brief log message indicating what the changes were and again, leave the file checked-out to capture changes by the system or other users
Now SVN is a proper centralized source control system. They have excellent documentation on setting up a repository. This is very useful for system admin scripts.
Although most system administration related scripts won't ever have "releases" or "branches", you probably still want to follow the SVN guide and create at least a trunk in case you ever do need to tag a specific version. There's no cost, so I use a trunk even though I've never used it because changing later is a problem.
With SVN you'll want to keep an updated local working copy ("tip") either on a shared NFS location or locally on each server. How you do it is up to you, just create a cronjob to run "svn update /path/to/tip" and then you can always run scripts from that path.
RapidSVN is a great tool, well maybe not great, but works very well for sys admin anyhow and its readily available. So check out your own working copy of the trunk with RapidSVN. I configured RapidSVN to use gedit as my standard editor and meld as my diff tool.
This gives you everything you need for day-to-day creating and maintain system configuration files and your toolbox of scripts for automated system maintenance.
