Ideally, it would be nice to have everything on a system under some kind of formal revision control. This would let everyone see who changed what, when they did it, and nominally, why.

RCS

Until such time as our grand unified revision control system using Subversion is working, we're making due with that old stand-by, RCS. Selected config files are under RCS. You can generally recognize such files by the following:

• Existance of an RCS $Id$ line in the file
• Presence of an ./RCS subdirectory in the config file's directory
• Permission modes such that the file is read-only for all
• Ben yelling at you for not using RCS

Some files have group ownership of sysadm, and can thus be checked out using a regular user account. Some files have to (or really should be) owned by root. Those need you to run the RCS commands as root using sudo. That looses the benefit of RCS tracking who did what, but at least it still tracks what was changed when. And you can always put your name in the checkin comments.

RCS cheat sheet

Basic process

1. Check out and lock the file: co -l foo
2. Make your changes: $EDITOR foo
3. Check in the file, unlocking it, and leaving a read-only copy in the working directory: ci -u foo
4. Lather, rinse, repeat

Other commands

• Checkpoint changes without unlocking: ci -l foo
• See the current status header of a file: rlog -h foo
• See the complete change log: rlog foo
• Compare the working copy to the last saved revision: rcsdiff -u foo
• Lock without checkout (useful if file changed outside of process): rcs -l foo

More information

For more info, see: rcsintro(1), ci(1), co(1), rcs(1), rcsdiff(1), ident(1)

Subversion

NOTE: We're not using this Subversion idea. We tried something like it, and it went badly. More effort likely could make it workable, but we never bothered.

Subversion planning

We initially decided to go with Subversion, as it's similar to the CVS/RCS tools many are familar with, we had some expertise in the group, and Subversion is a well-known project.

After some discussion and prototyping, a message was posted by our SVN guru (Paul Lussier) describing what he learned. There was some further discussion here, here, and here.

We decided to go ahead and put (almost) all of /etc/ and /usr/local/adm/ under revision control. Announcement. There was some follow-on discussion about the performance of asvn and maintaining permissions.

That initial experient went awry, apparently due to bugs in the "asvn" script we were using at the time. See this list discussion. As of this writing, we don't have a real solution in place for revision control. There are some scattered RCS directories around, but I'm not sure everyone is using them. -- BenScott - 03 Apr 2006

Subversion implementation

(Editor's Note: Most of this is NOT in effect as of 3 Apr 2006.)

At this moment in time, we will be keeping all/most configuration files under revision control using svn (subversion). This is similar to CVS/RCS/SCCS and other file version control tools, but works much better with directories of files.

The following was issued by Paul Lussier (our svn expert). Please update it as situations warrant.

Here's the layout of the repository so far:

  gnhlug/
        branches/
        production/liberty/
                        usr.local.adm/
                                     AdminContacts
                                     ChangeLog
                                     gnhlug-10-Feb-2006.tgz
                                     CentOS-4.2/
                                     changes/
                                     pkgs/
                                     user-keys/
        tags/

branches and tags are currently unused. I doubt we'll ever need to use tags, but I can see us using branches for "playing" with things outside of the "production" tree. For example, suppose you want to play with a firewall config file, and you want to check out the repo to your home system and test the config out there. Create a private branch under gnhlug/branches/ by copying HEAD (i.e. production) to it, and then you can use rev-control on your private branch without affection what's actually in use. When/if this situation arises, I'm happy to help out.

To get started, if you want to check out the repo, on liberty find a place to check it out to in your homedir:

    mkdir ~/sandbox
    cd ~/sandbox
    svn co file:///usr/local/svn/gnhlug gnhlug

You should end up with the above described hierarchy in your sandbox dir. If you want to check the repo out to your home system, first do this:

On the system you wish to check the repo out to, edit ~/.subversion/config (this will get created the first time you run svn...). Uncomment the line containing '[tunnels]' and create a blank line below that as well. Then add the following line:

gnhlug = ssh -p 1776

You should have something similar to:

[tunnels] gnhlug = ssh -p 1776

save'n'quit.

Then, as on liberty, find a location to check out the repo to:

    mkdir ~/sandbox
    cd ~/sandbox
    svn co svn+gnhlug://liberty.gnhlug.org/usr/local/svn/gnhlug gnhlug

You should get the repo checked out into ~/sandbox/gnhlug

Because of the rpm's in this repo, it was taking a really long time to check this repo out. I got fed up with waiting to check it out, and ended up deleting the files from repos (not from the actual file system though). There's no need to have rpms and tgz's in our repo when we can always get them elsewhere on the net. If we have rpms that we've built, then we want the source trees under rev control, not the binaries themselves. I've also set an ignore property on the repo to ignore files of type '*.[tgz,tar.gz,bak,~,rpm]'. This will allow us to keep these files in the working copy of the checked out repo on disk, but have subversion ignore them so they don't get accidently checked in and clutter things up.

Play around with this repo if you want, get familiar with svn, do whatever. If you have questions, let me know, I'm glad to help.