



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Community
Ask the community for help and clear up your study doubts
Discover the best universities in your country according to Docsity users
Free resources
Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors
Cvs, or concurrent version control, is a free and open-source software used by multiple developers to share code, keep track of changes, and maintain different versions of a project. A step-by-step guide on how to set up a cvs repository, check out the code, commit changes, add new files, get the latest version, remove obsolete files, and compare changes. Cvs is particularly useful for large-scale projects and allows for parallel development, rollbacks, integration of changes, and version management.
Typology: Study Guides, Projects, Research
1 / 5
This page cannot be seen from the preview
Don't miss anything!
CVS stands for Concurrent Version Control. It’s free, open-source software used by multiple developers to share code, keep track of changes, and keep different versions of a project. it can be (and is) used for large, wide-scale projects, such as the Gnome interface. You’ll be using it in your projects to ease the problem of many people working on the same codebase.
Allows you to keep a ’master’ source tree and have each user check out their own private version of the tree. This allows for:
I’ve placed a directory on nexus in
~brooks/public_html/examples/cvs-code
that you can use throughout this tutorial. You should treat this as an existing codebase that you’re going to move into CVS, check out into a shadow tree, modify, and check back in.
Create a directory where the ’master’ version of your code will reside. This will need to be readable and writable by everyone on the project. If you’re using UNIX and have the appropriate privileges, you might consider making a separate group for access. You’ll need to set an environment variable to tell CVS where your master directory - you can do this with:
setenv CVSROOT /path/to/my/master/directory (for tcsh users)
or
CVSROOT=/path/to/my/master/directory export CVSROOT (for bash users)
Then do:
cvs init
to set up the appropriate subdirectories under $CVSROOT. You’ll probably have a hierarchy of files somewhere that you want to add in to the hierarchy. They could be either third-party software (e.g. java libraries) or code you’ve developed yourself. To add these to your repository, do:
cvs import
For example, cvs import ./c++code myCode start takes the code in the directory ./c++code and adds it to the repository. If you look at the working directory that’s been created, you’ll see a directory called CVS. This is where CVS does its bookkeeping - keeping track of the CVSROOT variable, what’s been checked out, and so on. You shouldn’t need to make any changes to these.
The top directory in the code hierarchy is called ’c++code’. To initially create a shadow tree in your own home directory, cd to wherever you want the shadow tree to be and type:
cvs checkout c++code
This creates the directory ’myProject’ and populates it with all the source files. If you just wanted to check out a subset of the tree, you could do something like:
cvs checkout ’c++code/c++code/schedules’
Now, go ahead and make some changes to the code in your local version of the tree.
Once you’ve made your changes, tested them, and you think they’re stable enough to save permanently and share with your group, you want to check them back in so that other people can get them. To do this, if you edited Linear.C in mult-producer/schedules, you would type:
You may want to know how your version of a file compares to the one in the repository. (What did I change in here, anyway?) cvs has a diff tool, just like regular UNIX: cvs diff Linear.C will compare the version of Linear.C in your working di- rectory to the one in the code repository. To see who made what changes, do: cvs log Linear.C This will print out a summary of the change log (which everyone commented in. Right? Right!) To see the status of a particular file (the version, whether your working version is up-to-date, when it was last checked in, etc.) you can do: cvs status ¡filename¿. This is nice if you just want to see whether you’re up-to-date without having a merge move everything around on you. (see below)
Suppose you’re editing a file, and you go to update, and the version in the repository has changed. (Your partner has also edited the file.) If the two can’t be merged, CVS will give you a warning, save your original file as
.#filename.C.versionnumber (e.g. .#Linear.C.1.4)
and mark the changes in the new file, pointing out both your version and the repository version with
<<<</>>>>>.
CVS will not let you check this file back in (commit it) until you’ve resolved these discrepancies. (by hand - it’s not that smart.) There are lots of other things you can do with cvs, but these are the basics. For example, you can tag certain versions (alpha/beta releases) you can place the repository on the network, you can read and write-lock files, you can have CVS notify users when a file is checked in, and lots of other stuff. Most of the time, you’ll use the commands below.
There’s plenty of information about CVS out there. Two good sources are the man page and the following URL:
http://www.cvshome.org/docs/manual
http://cvsbook.red-bean.com/
is an online book about CVS and opensource development. This has some nice examples (an essential with CVS!) The GNU manual for CVS is at:
http://www.gnu.org/manual/cvs/html_chapter/cvs_toc.html
Emacs also has tools called PCL-CVS and VC that serve as a frontend for CVS, if you’re an emacs fan.