By Jim Ries
CVS (Concurrent Versions System) is an open source version control system for Unix and Unix-like platforms. CVS is the version control system of choice for projects hosted on darwin.rnet.missouri.edu, including the Monsanto Swine Genomics Project. A complete CVS manual is available.
CVS is extremely useful when multiple developers want to work together on a project. It allows developers to easily keep up to date with the latest changes, and also to make "local" or "test" changes without causing problems for others.
You must setup your environment as follows when logged in to Darwin for using CVS:
If you wish to use CVS on a remote platform (e.g., a Windows-based PC) to access a repository which is stored on Darwin, you should setup your environment as follows:
Note: If you wish to use CVS on another remote platform (e.g., RedHat Linux) and would like to build the executables, I would be happy to include them here for others to download. Just send the results to JimR@acm.org.
CVS allows one to "checkout" from and "commit" files to a shared repository. The repository is essentially a library containing the current revision and all previous revisions of various source (and possibly binary) files. Normally, several developers will setup projects on which they will all be working and then "checkout" working copies of those projects. Each developer will make changes to their local versions of the projects and will then "commit" those changes to the repository. Periodically, developers will update (also via the "checkout" facility) their local projects to incorporate changes the other developers have made.
Arturo and Jim are working on a project called "coolstuff". Arturo checks out a copy of the project to his working directory on darwin, edits a file, and commits his change:
cvs checkout coolstuff
cd coolstuff
vi my.c
cd ..
cvs commit coolstuff
Jim has a copy of coolstuff on his local PC. Jim is changing another file.
cd coolstuff
vi somethingelse.c
cd ..
cvs commit coolstuff
When Jim is finished, he decides to get everything up-to-date
cvs checkout coolstuff
At this point, Jim notices that new changes to my.c have come in from Arturo. Since CVS is file-based, it is POSSIBLE that changes to somethingelse.c are now incompatible with the change from Arturo to my.c. However, this is not typically the case and can generally be avoided by employing good design techniques.
If Jim and Arturo had made changes to the same file, CVS would have attempted to merge these changes when a commit was done. Most often, CVS can successfully merge changes, but it will report an error and give additional information if it cannot merge changes (e.g., one party has deleted a function while another has modified the same function).
To add files to the coolstuff project
cd coolstuff
cvs add added1.c
cvs add added2.c
cd ..
cvs commit coolstuff
This one is a little confusing. It uses the "import" command. To create the new project called "coolstuff":
Go to the coolstuff directory
cvs import coolstuff vendortag releasetag
cd ..
mv coolstuff coolstuff.bak
cvs checkout coolstuff
Compare coolstuff and coolstuff.bak to be certain all went as expected.
rm -r coolstuff.bak
The vendortag and releasetag aren't particularly useful as far as I can tell. I use "JimR" as the vendortag and "initial" as the releasetag.