Here’s a handy post I did on getting CVS set up on the servers at Berkeley.
After hearing several horror stories of programs magically blowing up
and people having to start over because I can’t find the bug, or people
keeping 8 backup copies to make sure nothing goes wrong, I find myself
in the rare position of making up for my flamewar post of earlier (sorry
about that) by doing some community service. How? If you’re working on a
big project, *especially* with partners (later on), a version control
system is just what you need.
CVS (Concurrent Versions System, not cyclic vomiting syndrome) is a
system that manages code. It has several uses, but those relevant to our
— CVS keeps track of every file change you make, and can jump back
to any version of a file. It does this by keeping logs of how you
change files, thus saving a lot of space (one copy of a file with a list
of changes instead of multiple copies) and helping gobs when you’re
trying to figure out why your latest version broke.
— CVS is already on the Soda servers, so using it to manage your code
means your code is in two places at all times, on the Soda servers and
your laptop. You drop your laptop and corrupt your project 2 hours
before the deadline – its okay! Run to the nearest linux box and check
out your code.
— Many IDEs plug straight into CVS, and will manage your code and your
CVS repository for you almost out of sight. Emacs has a context menu
that appears when you’re working in a CVS-managed directory. Eclipse
integrates very well also (and there is an Eclipse plugin for C editing!
If you’re running EMACS and hating it, check out
— CVS also does a whole lot of fancy teamwork features, so that
several people can work on the same file/project, and when you commit
your changes to the server, it will show you what changed from your
version to the current version on the server, show any collisions (place
where you edited code that was edited in the meantime by someone else)
and a whole list of cool stuff.
— CVS allows you to “branch” your code – save the point you are now, call it something else, work on it and experiment, and either “merge” the changes back into the repository, or abandon it. Great for experimentation!
OK, so hopefully i’ve convinced you that CVS is a good thing to have.
There’s many alternatives, and CVS is not the newest (Subversion is the
CVS “replacement” but since CVS is already on Soda’s boxes, roll with it
There’s a couple of steps to getting everything set up. The big picture
1. Create a repository on a server somewhere with SSH access. We’ll do
this with your handy home directory in Soda!
2. Import your current projects. BACKUP YOUR DATA BEFOREHAND SO THAT YOU
CAN SCREW UP AND START OVER!
3. Export your newly imported projects so that the folders gets little
“CVS” subfolders that identifies them as being managed by CVS
4. Understand the checkout-edit-update-commit cycle (without the update
in the case when there’s only one person working on one computer)
5. Get your IDE to work with CVS
6. Check in your project as often as possible as you work on it! (This
is a style thing.
So, let’s get cracking.
Setting up CVS / Creating a repository
Jump into the terminal in soda, hit your home directory (or wherever you
want a “repository” subdirectory) and type “cvs init”. This should take
a couple of seconds, and return with nothing. Check your current working
directory, and there should be a “repository” subdirectory. Yay, CVS
is ready to go!
You want to set up your environmental variables so that there is a
“CVSROOT” variable pointing to this repository directory. This helps CVS
to know where it should create its database. I set up my environmental
variable inside .bashrc in my home dir, like so:
setenv CVSROOT /home/cc/cs61c/sp07/class/cs61c-xx/repository
This doesn’t work when you SSH in (i dont have the skillz or the time to
look up the right place ) but yeah, put it somewhere! All that this
does is you don’t need to type “-d
commands. More on this later! The point is, you want to know where your
repository is at.
Importing current projects
So, presumably you have some code somewhere that you want to put into version control. For example, you just copied over the fresh fresh code from ~cs61c/proj/01 or something. Let’s quickly talk about some terminology:
* import = insert files as a new project into CVS
* checkout = create a project on your harddrive, fresh from the latest files on the server
* project = a base directory of a directory structure that is managed by CVS
* commit = write the files you changed to the server
* update = updates your local code to reflect the server’s latest code
these are the basic 4 things you’ll be doing. So lets look at command structure:
cvs import -d
or, to make it easy
cvs import -d ~/repository proj1 proj1 initial
do that now with your project. You’ll get a nice output telling you how you just imported a new project and all the files that goes in.
Now *MOVE THIS CODE AWAY*, you can even delete it. I like to keep it somewhere else until i know that i’ve got CVS working right..
CHECKING OUT A PROJECT!
Now, to let CVS manage this project you just imported, check out the project to your workspace.
cvs checkout -d ~/repository proj1
now it’ll spit all the files back out (hopefully!) and when you take a look, there’ll be a CVS subdirectory.
go ahead and be productive, edit and go wild!
CHECKING IN FILES AS YOU EDIT
I like to check in fairly often. As in, once every 30 minutes to about once every couple of hours. When you’ve made a significant change, its definitely a good idea to commit. And if you want to experiment, use commit a lot, and read up on branching.
To commit your newly saved files:
cvs commit -d ~/repository -m “message for this commit”
Emacs has a bunch of keyboard shortcuts, and Eclipse allows you to check in projects from CVS directly into the workspace. You can, of course use the shell as always.
GETTING BACK OLD VERSIONS & COMPARING VERSIONS
So let’s say you just broke something in your code and you want to look how it differs from earlier, or you want to replace it with an earlier version of the file. Eclipse does this great. Also, you can see the differences between revisions:
cvs -d repository-location diff [[-D date] || [-r revision_nr]] [[-D date] || [-r revision_nr]].
Thus, you can say. compare my current version with some other version or date. CVS works on a 18.104.22.168 versioning system, and when you check in the version automatically increases.
MORE MORE MORE?
There’s a LOT more to CVS, but this should be enough to get people running. I’m also falling asleep on the keyboard – this project is taking up a lot of time – so good luck to everyone!