OK, hi again. Since I'm using CVS already a lot to bring you this site here I should write something about it. CVS is really a useful tool for maintaining equal states in different places, being able to go back to a previous versions and letting different people work with source code at the same time. Normally you would think that when someone is working on some text this text has to be blocked for others since otherweise both people might undo each others work. Thats what RCS thinks too ( Revision control system - RCS - is an older system for version control which cvs supersedes) and therefore it locks a file when someone is working on it. But with CVS it's different. Both people can work with the same file. The source code is put into a repository from where each developer has to "check out"../../ the code. Nobody is allowed to do coding direct in the repository. So every developer checks out a copy of the current work status contained in the repository. On this copy they code.Sure it might happen that they undo each others work but thats a communication problem between the two people, not cvs's . But the source code in the repository won't neccessary be affected by their undoing since when they try to check in their changes, cvs calls this commit, cvs will either apply their changes to the code if that part that they have been working on is unchanged since when the person checked it out. But if two people worked on the same thing cvs will not apply the seconds persons changes to destroy the work of the first persons commit but rather show the second person the new code in the repository so that the second person can fit in his change to combine it with the others work. This has to be done manually since cvs isn't that bright yet (Otherwise it could code itself and the programmers wouldn't be needed any longer).
CVS works line-oriented in text files without knowledge of syntax rules. Therefore changing a line's position or inserting some spaces is a sufficient difference for cvs to label it with a new version number. Resulting from these facts cvs doesn't give version info to directories and binary files since they aren't what it deals with: text files.
Getting help:
cvs --help , cvs --help-options or cvs --help-commands gives you some general help on the command line. To get help to a certain command type cvs -H command. You can also read the info cvs pages or read the same text in postscript form something like /usr/local/cvs-*/doc/cvs.ps (the * indicates the version number of your cvs).
Creating a repository:
First you have to chose where your repository shall reside. Then you tell cvs where it lies with:
export CVSROOT=/path/to/the/repository
cvs init
Alternatively you can do it with:
cvs -d /path/to/the/repository init
Setting up a so called pserver for remote password connects:
- have something like
cvspserver 2401/tcp in your /etc/services
- if you don't use
tcpwrappers put this into your /etc/inetd.conf:
cvspserver stream tcp nowait root /usr/bin/cvs --allow-root=/usr/local/cvsroot pserver
- if you use
tcpwrappers put this into your /etc/inetd.conf:
cvspserver stream tcp nowait root /usr/sbin/tcpd /usr/bin/cvs --allow-root=/usr/local/cvsroot pserver
- then you have to restart
inetd (most probably with /etc/init.d/inetd restart)
Commands:
The command syntax is something like:
cvs global_option(s) command command-option(s)
tag -b split a project into development and stable branch for example
update -j merge the development and stable branch again
admin -kb mark file as binary (so that diff doesn't bite it's teeth out)
Global Options:
-T /absolut/path/to/tempdir has precedence over $TMPDIR
-v --version shows version number and copyright remarks