Version Control

A little background:

SCCS and RCS basically operate at the same level. SCCS is older, and there was no open source version available until recently, so it was not available on all platforms. RCS has been around a long time, and the source code has been freely available. Emacs has a vc facility that allows the user to manipulate both RCS and SCCS files transparently.

CVS is a system that works on top of RCS. Originally, CVS called RCS programs, now the RCS functionality is folded into CVS. CVS allows developers to operate on files in a concurrent fashion, whereas RCS and SCCS are really set up for locking files so that others cannot modify them. If two developers modify the same file, CVS attempts to merge the changes, and if the changes cannot be merged, it notes the conflict.

Here's what we get with CVS and version control in general.

1. CVS provides platform independence. I can check out the Ptolemy II system under NT with Cygwin or under Solaris, and the CRNLs or NLs in text files are handled properly
2. The directory structure of the package is automatically generated when I do 'cvs checkout ptII'. This means I can build a tree in no time, try out something wild, and then abandon the tree or check in my changes as I choose.
3. CVS allows for concurrent modification of files. Yes, problems can result, but this is a serious win. Professor Lee can hack away on his laptop while traveling, and then easily check in all his changes when he dials in. This is a big win.
4. Fixing bugs is much easier. I can narrow the time the bug was introduced down by checking out trees from different dates and then running a test. I can then look at the log messages for the files that were changed when the bug was introduced and get an idea what was causing the problem. Or, I can tell the author that their changes broke something, and that they need to have a look.
   Version control is a serious win for having accountability.
5. The GSRC machine gigasource.eecs.berkeley.edu provides CVS support so that projects with developers in more than one university can easily set up and share a development tree.
6. CVS can handle binary files, so I can check in jar files (collections of java .class files), and PDF files. Basically, the entire release that we ship is checked in to CVS. This makes it very easy to create interim developer's releases
7. By using CVS branches, I can easily create a release tree. I freeze the features of the release tree, and then fix bugs in the master tree and the release tree. The changes I made are visible in the log file, as is the location where I made the branch.
8. The CVS module facility seems like it could be of use in software systems that include subsystems
9. There are web based interfaces to CVS. Lots of projects are doing distributed development with CVS.
10. CVS and version control systems in general are an excellent form of backup. When I work on a website, I put it under CVS, so then if I destroy a file, I can easily get a recent copy without bothering the backup operator. I work on a PC, but my files are in CVS repositories on reliable and backed up Unix boxes.