CVS Server setup
Quick guide
This guide describes very briefly the installation of cvs server on Fedora Core 2. This guide contains some errors. Use at your own risk. I don’t update this page since I have no access to Fedora Core 2 systems anymore. See for more background information on setting up CVS: cvsbook.red-bean.com.
* Verify you have cvs installed:
rpm -q cvs cvs-1.11.22-14.fc9.i386
* If not, install it using either
rpm -ihv cvs-1.11.22-14.fc9.i386.rpm or yum install cvs
Also be sure you have xinetd installed.
* Edit (as root) the file /etc/xinetd.d/cvs:
[root@box ix]# cat /etc/xinetd.d/cvs
# default: off
# description: The CVS service can record the history of your source \
# files. CVS stores all the versions of a file in a single \
# file in a clever way that only stores the differences \
# between versions.
service cvspserver
{
disable = no
port = 2401
socket_type = stream
protocol = tcp
wait = no
user = root
passenv = PATH
server = /usr/bin/cvs
env = HOME=/var/cvs
server_args = -f --allow-root=/var/cvs pserver
log = /var/log/cvslog
# bind = 127.0.0.1
}
* Issue following commands as root:
export CVSROOT=/var/cvs
useradd -M cvs # create user cvsuser without creating home dir
# give that group ownership of the cvs repository
chown -R root:cvs /usr/local/cvsroot
# set the sticky bit so that files created by a group member stay owned by the group
chmod -R g+srw /usr/local/cvsroot/
touch $CVSROOT/locks
cvs init # creates $CVSROOT/CVSROOT
cd /root
cvs checkout CVSROOT
usermod -G cvs giany # each Unix user that needs access to the repository
* Edit /root/CVSROOT/config like this:
# Set this to "no" if pserver shouldn't check system users/passwords
SystemAuth=no
# Set `TopLevelAdmin' to `yes' to create a CVS directory at the top
# level of the new working directory when using the `cvs checkout'
# command.
TopLevelAdmin=yes
and commit:
cd cvs commit CVSROOT/config
Allow users
* To add user giany:
htpasswd -d -c /var/cvs/CVSROOT/passwd giany
To add additional users:
htpasswd -d /var/cvs/CVSROOT/passwd aibo
* Add a colon and ‘cvs’ after each encrypted password:
giany:RMAAvN0lxM.g9:cvs
* Edit /var/cvs/CVSROOT/cvswrappers:
[root@box CVSROOT]# cat cvswrappers # This file affects handling of files based on their names. # # The -m option specifies whether CVS attempts to merge files. # # The -k option specifies keyword expansion (e.g. -kb for binary). # # Format of wrapper file ($CVSROOT/CVSROOT/cvswrappers or .cvswrappers) # # wildcard [option value][option value]... # # where option is one of # -f from cvs filter value: path to filter # -t to cvs filter value: path to filter # -m update methodology value: MERGE or COPY # -k expansion mode value: b, o, kkv, &c # # and value is a single-quote delimited value. # For example: #*.gif -k 'b' *.gif -k 'b' *.tga -k 'b' *.bmp -k 'b' *.psd -k 'b' *.tif -k 'b' *.png -k 'b' *.iff -k 'b' *.aiff -k 'b' *.obj -k 'b' *.dat -k 'b' *.exe -k 'b' *.com -k 'b' *.dll -k 'b' *.dsw -k 'b' *.dsp -k 'b' *.lwo -k 'b' *.lws -k 'b' *.p -k 'b' *.ico -k 'b' *.frx -k 'b' *.class -k 'b' *.jar -k 'b' *.zip -k 'b' *.lzh -k 'b' *.lha -k 'b' *.rar -k 'b' *.arj -k 'b' *.arc -k 'b' *.avi -k 'b' *.mov -k 'b' *.asf -k 'b' *.smk -k 'b' *.jpg -k 'b' *.mpg -k 'b' *.swf -k 'b' *.frx -k 'b' *.fli -k 'b' *.flc -k 'b' *.tiff -k 'b' *.bin -k 'b' *.dat -k 'b' *.wad -k 'b' *.ppt -k 'b' *.pdf -k 'b' *.3ds -k 'b' *.max -k 'b'
* Restart xinetd:
/etc/init.d/xinetd restart
* Try if it works:
export CVSROOT=:pserver:giany@localhost:/var/cvs/
cvs login
== Start a new Project ==
To start a source repository:
mkdir project cd project cvs import -d project Your_name initial
Check out the sources from the CVS repository with the following command:
# cvs co -P project cvs checkout: Updating project
which will create a sub-directory named prj_name with the sources and each directory will have a sub-directory named CVS that contains info about the repository sources. Once you’ve checked-out the sources, you need not define $CVSROOT to work within the local sources. All the cvs commands will work, if they’re invoked within the local source directories, and it’s local host access.
Compare Local Changes
Suppose you modified any of the checked-out or local sources. To compare the changes you’ve made to the repository sources:
cvs diff [source_file]
where you can give one or more optional source_file names, else cvs will compare all files in the current directory and all subdirectories.
However, be aware that this will not give any information about changes between the local source file and any changes that have been checked in by others. Only changes that have been made to the local source file and it’s original source.
History of Changes
To look at the history of changes:
cvs log [source_file]
Status of Changes
To check the current status of a source_file or all the files:
cvs status [source_file]
A couple of useful C-shell aliases to create are:
cvsstat shows just the status of all files
alias cvsstat ‘cvs status \!* |& grep Status:’
cvswhat shows the status of files that are not “Up-to-date”
alias cvswhat ‘cvs status \!* |& grep Status: |& grep -v “to-date”‘
Remove a File
To remove a file from the repository:
rm source_file # must first remove it locally
cvs rm source_file # schedules it for removal
Add a File
To add a file to the repository
vi source_file # create the file first
cvs add source_file # schedules it to be added
Move a File
This can not be done cleanly at the local level. The best way to do this with CVS is to go to the cvsroot repository and move the file or directory within the repository there (if you are interested in keeping the history of changes). The cvsroot repository keeps all files in their RCS form of filename,v . The next cvs update will manifest the file move.
Check In Local Changes
Once you’ve made all the changes you care to for the current batch then:
cvs ci [source_file]
which checks-in the changes and updates the repository sources. CVS will pop-up an editor session where you can describe the changes made, which appears in the source_file log for each file affected.
Update Local Sources
If many people are working on the repository, you can obtain any changes in the repository that have been made since you’ve checked out the sources with:
cvs update [source_file]
and if there are conflicts, then CVS will notify you and flag it in the sources. On the Crays, I’ve noticed that CVS can’t use the “patch” facility hence it will default to copying, which is not a problem, so ignore such messages.
Tagging Sources
You can “tag” the current set of changes (revisions) with:
cvs tag tag_name
then this set of local sources can be recovered with this “tag_name”
Another option is to tag the repository sources with
cvs rtag tag_name prj_name
which you want to do for each “release” of the code, so you can always backtrack any bugs to the version released to the users.
Creating Patches
You can create a “patch” file of changes with
cvs rdiff -u -r tag_name -r initial prj_name > patch_file
which will have all the changes you’ve made between the “tag_name” version and the “initial” version. You can also create patch files between any two tags.
You can also create a “patch” file of your local changes with:
cvs diff -N -u -r tag_name > patch_file
Backing Out Changes
Suppose you modify a file, but don’t want to keep the changes:
rm source_file # remove it from local sources
cvs update source_file # get a new copy from the repository
Using Branches
Working with branches is one of the more difficult concepts to master with CVS, but it is one of the most useful for an active development project.
The concept is that the software project has made a release, say version 3.1.0, and work is now progressing on version 3.2. However, a bug was discovered in the released 3.1.0 version, which you want to fix. Suppose that the project was tagged with prj_3_1_0. Also, it will be assumed that it wasn’t marked as a branch (-b).
1. Need to tag the current tag sources as a branch with
cvs rtag -b -r prj_3_1_0 prj_3_1_0_branch project_name
2. Check out the given tagged version into a directory named prj.3.1.0 with
cvs checkout -d prj.3.1.0 -r prg_3_1_0_branch project_name
3. Get into the prj.3.1.0 directory for further work.
4. Make whatever changes to the sources, which will be identified as version 3.1.1
5. Check in changes for this branch as
cvs commit
6. Tag this version with
cvs tag -r prj_3_1_1
7. Make a tar ball for distribution, and remove the branch project directory, which is no longer needed.
8. If there are any fixes that can be merged into the main development branch. (This only works if the differences between this branch and the development branch are fairly small.) Get into a checked-out project directory (not the branch directory which should have been removed).
9. Merge the branch changes with the main development branch with
cvs update -j prj_3_1_1
Carefully, note the output, and resolve any conflicts, and test changes.
10. Note that merges can be incorporated into other branches by applying them to whatever checked-out version.
Sticky Tags!
Generally, what happens when a tagged version is checked out:
cvs checkout -d prj.3.1.0 -r prg_3_1_0 project_name
Something in the CVS directories makes the tag “sticky” and no changes can be updated or checked in. An attempt to cvs commit any local changes usually results in a message saying the “sticky” tag is not a branch!
1. The tag needs to be made into a branch with
cvs tag -b -r prj_3_1_0 prj_3_1_0_branch
Where the -b is the key here to making a branch.
2. Update the current working version as a branch with:
cvs update -r prj_3_1_0_branch
This will not affect the source files, only the CVS/Entries files will be updated to a different “sticky” tag … a branch in this case.
3. The changes can now be checked in to that branch with
cvs commit
4. Changes in this branch can be merged into the development branch. (See the latter part of “Using Branches” for more details.)
More Info
To get more usage info:
cvs --help # usage info and general cvs-options
cvs --help-commands # list & description of commands
cvs --help-options # general cvs-options
cvs --help command # command specific usage & command options
and
man cvs # gives an overview
Related posts:
Leave a Reply