Basic process

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

• Existance of an RCS $Id$ line in the file

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

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

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

Subversion

Subversion planning

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.

We had somewhat decided to go with svn. The reasons are ... .

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

You may also be interested in the discussions preceding this. See the following threads:

• Revision Control

Comments?