Download CVS: Setting Up and Using Concurrent Version Control for Parallel Development and more Study Guides, Projects, Research Computer Science in PDF only on Docsity!
About CVS
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.
1 Version Control - what is it? why is it useful?
Allows you to keep a ’master’ source tree and have each user check out their own private version of the tree. This allows for:
- Parallel development.
- A way to ’roll back’ changes.
- A way to integrate changes from different developers.
- A way to keep several versions of a codebase on hand.
- Automated annotations of all changes.
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.
2 Step 1: set up a repository
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 <version-name>
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.
3 Step 2: Check out the code you’re interested
in.
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.
4 Step 3: Commit changes.
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:
8 Step 7: Comparing changes
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)
9 Step 8: Merging
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.
- checkout (co)
- update
- add
- remove
- commit
- diff
- export
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.
