Version Control

start > Best Practices > Software > Sources > Code Control for CSC

Code Control for CSC

Created by gattis. Last edited by gattis, 2 years and 208 days ago. Viewed 5 times. #2
[diff] [history] [delete] [lock] [view] [edit] [new] [copy] [rdf]
wiki monitor logo Aa Am



A CVS server has been set up on You have to have an account on that machine to be able to connect. Alan Gattis can make accounts for you. The repository will be backed up nightly. The repository should be accessible by any CVS client, such as WinCVS (a stand alone Windows application) and Tortoise CVS (which integrates with Visual Studio and even Windows Explorer.

Once you have an account, your CVS client will need to know how to build your CVSROOT string:

This tells your client that the method for connection is via a “pserver”, what your userid is, and that the repository is stored in /home/cvsroot.


There is already a project in the repository named “testproj” that was created for the purpose of letting folks play around with CVS. If you want to kick the tires, try an unfamiliar CVS command, and so forth, feel free to use this project instead of experimenting on a real project. Also, feel free to create your own projects.

Getting Help

I can walk you through using CVS if you've not used it before, or if it's been a while since you've used it and you want to refresh your knowledge. I also have a CVS book if you just want a reference.

Reminders and Advice

Remember that binary files need to be identified as such when added to a project. If you don't do that, you run the risk of CVS changing the file. There's not usually a need to add buildable files to the repository, so .class, .o, and executables often are just wasting space in a repository.

Remember also that CVS will translate text files into native formats for the operating system on which you run your CVS client. So, it is a bad idea to checkout a project on Windows, transfer it to Unix to do your work, and then transfer it back to Windows for a commit. Instead, just checkout the project on the machine on which you intend to do development. In fact, copying entire projects around after a checkout is so inconvenient that it will likely lead to several bad habits and plans involving this should likely be revisited.

Good source code control habits include:

  • Never commit changes that do not compile. If you do, you will prevent the rest of the team on the project from being able to work once they update their work areas (aka “sandboxes”.)
  • Try to organize your changes so that you can do frequent commits. Doing so minimizes the chances you will have to resolve a collision with another team member's code.
  • Create a tag for any significant milestone, including alpha, beta, and formal releases. Not only does this let you retrieve old code without having to remember individual file versions, but it potentially lets QA and OPS staff members to use CVS as well.
    • Last edited May 5, 2004
Monitor at CSC -- Return to WelcomeVisitors Click Here to Search
Subpages (2): CVS CVS Eclipse