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.
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
, 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
. 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
- Check out and lock the file:
co -l foo
- Make your changes:
- Check in the file, unlocking it, and leaving a read-only copy in the working directory:
ci -u foo
- Lather, rinse, repeat
- Checkpoint changes without unlocking:
ci -l foo
- See the current status header of a file:
rlog -h foo
- See the complete change log:
- 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
For more info, see:
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.
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
, 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
(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
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:
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:
gnhlug = ssh -p 1776
Then, as on liberty, find a location to check out the repo to:
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.