If this problem is due to my lack of experience using cvs, I'll be glad to
have someone point that out to me.
History/setup: I have a fresh clean install of RedHat 6.2. I would like
to preserve everything in and under my /etc directory. So, when I logged
in for the first time as root, I setup cvs:
export CVSROOT=/home/cvsroot
export EDITOR=/bin/vi
mkdir -p $CVSROOT
chmod ug=rwx,o=rx,g+s $CVSROOT
cvs init
cd /etc
cvs import -m "RedHat 6.2 install" etc v6_2 r1_0
That completed successfully, so I went for the checkout:
cd /
cvs checkout etc
It checked out the files in the /etc directory itself, but as the status
messages were scrolling by, I saw a bunch of '?' next to directory names
under /etc. Next, to verify the checkout went recursive, I did:
find /etc -name "CVS"
and confirmed that only files in /etc were checked out; none of the
subdirectories were checked out. This is problem #1. Also, if I try cvs
release to "undo" the checkout since it didn't work very well for me, it
shows the directories with '?' next to them again and says "unable to
release".
Problem #2: I edited /etc/profile to include the CVSROOT and EDITOR
environment variables, then ran cvs diff to confirm all the changes I had
made -- this worked correctly. However, when I tried:
cd /etc
cvs commit
I received an error message: "cvs [commit aborted]: cannot commit files
as 'root'". I then tried creating a new user, then using su - newuser,
but then I had some understandable permission problems in the /etc
directory.
What am I doing wrong?
Thanks,
Matt

If you wish to preserve /etc with CVS, do the following (rather than importing)
0) Make sure that you have a repository at CVSROOT (as you have done) and do
cd $CVSROOT
mkdir <your_hostname_here> # <-- put your hostname there
1) Create a top level CVS admin directory:
cd /
mkdir CVS
touch CVS/Entries
echo <your_hostname_here> > CVS/Repository
echo $CVSROOT > CVS/Root
1.1) Verify that everything is copacetic by doing
cd /
cvs -n updat -l
and you should see a lot of '? bin' etc messages
2) Add /etc to the repository
cd /
cvs add etc
You should see /etc/CVS/* populated, and etc mentioned in /CVS/Entries*
3) Choose the files you want to track, and populate. For example, if you
wanted to track inetd.conf, you would do
cd /etc
cvs add inetd.conf
cvs ci inetd.conf
3.1 Verify by doing
cd /etc
cvs diff inetd.conf # <-- try changing a byte
and/or doing
cd /var/tmp
cvs get <your hostname here>
cd <your hostname here>/etc
cvs diff inetd.conf
4) Get rid of output from files the you don't wish to track. For example, if you
don't want to track /etc/foo, you would do
cd /etc
echo foo > .cvsignore
cvs add .cvsignore
cvs ci .cvsignore
Iterate with all files that you do not wish to track.
5) CHECK THE PERMISSIONS! When doing cvs checkouts, its *REAL* easy to end
up accidently changing permissions on a critical file. I usually "fix" this
by writing a short shell script (called .cvsfix) that sets the permissions,
something like
#!/bin/sh
chmod 644 inetd.conf
chown root.root inetd.conf
added to the repository as
cd /etc
<create .cvsfix with contents above>
cvs add .cvsfix
chmod +x .cvsfix
cvs ci .cvsfix
You can test the script by doing
cd /etc
./.cvsfix
You probably should diddle the script to be independent of the "cd /etc" and
you should *not* use absolute paths in the script because you might be
working with a checkout in a different directory.
6) Symlinks are a pain. You have three choices
a) (dumb and dirty) check in the contents of each symlink (thereby making
it a separate file).
b) (ok but a little hard to manage) recreate symlinks as in 5) by adding
lines to .cvsfix
c) (hard but possibly elegant) figure out how to have cvs check in symlinks
asd symlinks (this is possible but I've never done it).
As for the error "cannot commit files as root", you have two choices:
a) (easy) Rebuild from the src.rpm and enable the ability to check in as root.
b) (hard) Design a security scheme using membership in system groups that
permits you to do "chmod g+w /etc". If you don't understand the
ramifications of adding group write permissions to /etc, go *DIRECTLY*
to a)
Hope this helps.

Note

You need to
log in
before you can comment on or make changes to this bug.