Create CVS Repository
To set up a CVS repository, you must define the environment variableCVSROOT to point to therepository directory.A good choice may be (C-shell example)
setenv CVSROOT /usr/local/src/cvsrootOnce $CVSROOT is defined then you can do
to initialize and set-up the CVS repository.This only needs to be done once.cvs init
CVS as a server
If you want CVS to work as a server then do the following steps. Thisonly needs to be done if you plan to have developers access your CVSroot from off the machine anonymously.
- Generally, it's a good idea to set up CVS as it's own user and group:
groupadd -g 8000 cvsgrp useradd -u 8000 -g cvsgrp -d /u/cvs -s /bin/sh \ -c "CVS Repository" -m cvs- Set the ownership of the $CVSROOT and set the setgid bit on thedirectory to propagate group ownership to any created files anddirectories.
chown -R cvs $CVSROOT chgrp -R cvsgrp $CVSROOT chmod -R g+s $CVSROOT- Made sure the cvspserver entry is in the /etc/services file
which should yield the following lines. (If not, then addthem yourself.)grep cvs /etc/servicescvspserver 2401/tcp # CVS client/server operations cvspserver 2401/udp # CVS client/server operations- Add an entry into /etc/inetd.conf to invoke CVS as a server
and signal the inetd daemon to re-read the configuration file with# CVS server cvspserver stream tcp nowait root /usr/bin/cvs cvs --allow-root=/usr/local/src/cvsroot pserverkillall -HUP inetd- If xinetd is used instead then create a configuration file in/etc/xinetd.d named cvspserver,(where the last line tells it the names of your repositories):
and signal the xinetd daemon to re-read the configuration file withservice cvspserver { socket_type = stream protocol = tcp wait = no user = root passenv = server = /usr/bin/cvs server_args = --allow-root=/usr/local/src/cvsroot pserver }orkillall -HUP xinetdcd /etc/rc.d/init.d ./xinetd reload- Create or edit the following files in $CVSROOT/CVSROOT
readers
- contains a list of pseudo usernames that can read fromthe CVS repository via cvspserver.
writers- contains a list of pseudo usernames can write via cvspserver ...this is not secure since passwd is passedas clear text.
passwd- create the encrypted passwd string with ( htpasswd from apache)
edit passwd to append `` :cvs'' to the pseudo_usernameentry. This is the user it will run as, and this will allow the pseudo user to write tothe history file.Note that the cvs user was defined above.htpasswd -c passwd pseudo_username
Local or Remote Access
There are several ways to access the CVS repository. The choice dependson how much access should be granted.
- anonymous - read only access:
give it the password given above.cvs -d :pserver:pseudo_username@cvshost.domain:/usr/src/cvsroot loginThe purpose of anonymous access is for users to get the most recentsources, but read-only. They can make changes, but can only generatea patch file,which should be sent to one of the developers.cvs -d :pserver:pseudo_username@cvshost.domain:/usr/src/cvsroot checkout project_name- local - read or write access - for active developers.
The user has an account on the CVS host, and they should be listedin the cvsgrp, and they can setHowever, CVS_RSH does not need to be set. See the example .cvsrcfile below.setenv CVSROOT /usr/src/cvsroot- remote - read or write access - for active developers.
The user should have an account on the CVS host, and they should belisted in the cvsgrp. It is possible to allow anonymous-likeaccess, but it will not be described here, since the password is sentas clear text, and it's not secure at all.Further discussions will assume that the SSH daemon is working on the CVS host,and that client-side SSH is there for the remote user.The user needs to define the following environment variables, which arenecessary, and a couple of helpful C-shell aliases. The definitionsare placed in the $HOME/.cvsrc file, which is serving double duty.The lines following the shell exit tells CVS what default flags touse for the given CVS command.
#begin .cvsrc setenv CVSROOT username@cvshost.domain:/usr/src/cvsroot setenv CVS_RSH ssh alias cvsstat 'cvs status \!* |& grep Status:' alias cvswhat 'cvs status \!* |& grep Status: |& grep -v "to-date"' exit # default CVS options diff -u cvs -z4 update -d -P checkout -PSource this file to set the environment variables or aliases with(C-shell)
source $HOME/.cvsrc
Initialize a Software Project Repository
To start a source repository:where prj_name is a descriptive name for the project vendor_name can be anything, and `` initial''is what I use to tagthe initial set of sources.If everything worked OK, then you can remove the original sources.(Don't try to `` check-out'' the repository sources into theoriginal source directory ... this usually causes endless problems.)cd prj_name cvs import -d prj_name vendor_name initial
Check Out Sources
Check out the sources from the CVS repository with the following command:which will create a sub-directory named prj_name with the sourcesand each directory will have a sub-directory named CVS that containsinfo about the repository sources.Once you've checked-out the sources, you need not define $CVSROOTto work within the local sources. All the cvs commands will work, ifthey're invoked within the local source directories, and it's local hostaccess.cvs co -P prj_name
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:where you can give one or more optional source_file names,else cvswill compare all files in the current directory and all subdirectories.cvs diff [source_file]However, be aware that this will not give any information aboutchanges between the local source file and any changes that havebeen checked in by others. Only changes that have been made tothe 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:A couple of useful C-shell aliases to create are:cvs status [source_file]cvsstat
- shows just the status of all files
cvswhatalias cvsstat 'cvs status \!* |& grep Status:'- 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 repositoryvi 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 todo this with CVS is to go to the cvsroot repository and move the fileor directory within the repository there(if you are interested in keeping the history of changes).The cvsroot repository keeps all files in their RCSform 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:which checks-in the changes and updates the repository sources.CVS will pop-up an editor session where you can describe the changesmade, which appears in the source_file log for each fileaffected.cvs ci [source_file]
Update Local Sources
If many people are working on the repository, you can obtain any changesin the repository that have been made since you've checked out the sourceswith:and if there are conflicts, then CVS will notify you and flag it in thesources. On the Crays, I've noticed that CVS can't use the `` patch'' facilityhence it will default to copying, which is not a problem, so ignore suchmessages.cvs update [source_file]
Tagging Sources
You can `` tag'' the current set of changes (revisions) with:then this set of local sources can be recovered with this `` tag_name''cvs tag tag_nameAnother option is to tag the repository sources with
which you want to do for each ``release'' of the code, so you can alwaysbacktrack any bugs to the version released to the users.cvs rtag tag_name prj_name
Creating Patches
You can create a ``patch'' file of changes withwhich will have all the changes you've made between the `` tag_name''version and the `` initial'' version. You can also create patch filesbetween any two tags.cvs rdiff -u -r tag_name -r initial prj_name > patch_fileYou 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 masterwith CVS, but it is one of the most useful for an active developmentproject.The concept is that the software project has made a release, sayversion 3.1.0, and work is now progressing on version 3.2.However, a bug was discovered in the released 3.1.0 version, whichyou want to fix. Suppose that the project wastagged with prj_3_1_0. Also, it will beassumed that it wasn't marked as a branch (-b).
- 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- Check out the given tagged version into adirectory named prj.3.1.0 with
cvs checkout -d prj.3.1.0 -r prg_3_1_0_branch project_name- Get into the prj.3.1.0 directory for further work.
- Make whatever changes to the sources, which will be identifiedas version 3.1.1
- Check in changes for this branch as
cvs commit- Tag this version with
cvs tag -r prj_3_1_1- Make a tar ball for distribution, and remove the branch projectdirectory, which is no longer needed.
- If there are any fixes that can be merged into the main developmentbranch. (This only works if the differences between this branchand the development branch are fairly small.)Get into a checked-out project directory (notthe branch directory which should have been removed).
- Merge the branch changes with the main development branch with
Carefully, note the output, and resolve any conflicts, and test changes.cvs update -j prj_3_1_1- Note that merges can be incorporated into other branches by applyingthem to whatever checked-out version.
Sticky Tags!
Generally, what happens when a tagged version is checked out:
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 ina message saying the `` sticky'' tag is not a branch!cvs checkout -d prj.3.1.0 -r prg_3_1_0 project_name
- The tag needs to be made into a branch with
Where the -b is the key here to making a branch.cvs tag -b -r prj_3_1_0 prj_3_1_0_branch- Update the current working version as a branch with:
This will not affect the source files, only the CVS/Entries fileswill be updated to a different ``sticky'' tag ... a branch inthis case.cvs update -r prj_3_1_0_branch- The changes can now be checked in to that branch with
cvs commit- 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:andcvs --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
A good book to have that covers a lot of the CVS details and filesis `` Open Source Development with CVS'',Karl Fogel, © 1999, Coriolis Group. ISBN 1-57610-490-7man cvs # gives an overview