CS 23 Software Design and Implementation

Lecture 19

Concurrent Versions System (CVS)

In the this lecture we discuss the Concurrent Versions System for managing source code for project teams.

We also discussed the design of the query engine but no notes are included here. Reason for that is that the design of the query engine is for you to do as part of Lab6.

Goals

We plan to learn the following from today’s lecture:

• How to manage a large number of source files when different peopel are concurrently working on them;
• How to use cvs;
• How to import a source tree;
• How to checkout a source tree;
• How to check for changes;
• Updating a file and doing a cvs update;
• Commiting the changes to the cvs; and
• Doing a log and diff agains the local tree and the repository.

Source code control - why you need it

When you move beyond a simple assignment, small code set, and toward large more complex source trees with multiple people working on the source code in parallel - you need needs to help manage the code:

1) to manage changes made by the group

2) to avoid conflicting changes

3) to track changes in the code

If you don’t use a source code control tool life can get very complicated so let the software tools help.

There are a number of source code control tools:

1) SCCS (source code control system)

2) RCS (revision control system)

3) Subversion (newer)

4) CVS (we will use this in the course and project)

My notes are incomplete here - and I apologies. But I want to capture the various scenarios for cvs that I went over in class. Note, Wayne keeps FAQ on cvs - check it out - but the notes below should be sufficient for you to manage your cvs account.

The first thing we would like to do is import a source tree for the first time in to my cvs account. Note you should replace “campbell” in the following with you username.

The import command. We import the lab5 source tree to the cvs under project campbell/indexing

The complete lab5 source tree is now signed in - that is all you have to do for the lab5. Perhaps you should sign in Lab6 in under project campbell/lab6

OK, lets sign out the complete source tree for the indexing under a different local source directory. We make a new directory called cvs in our local directory. Then we “checkout” the source tree for lab5 that we just imported.

Next, we can check the status of our checkout cvs project using “update”. There is nothing changes no update reflects this. Notice that the source tree is under campbell/indexing off the cvs directory that was created locally. And not that there is a CVS directory created when we checkout the source tree. From now on we do not need to specify the complete path “-d campbell@cs23cvs:/cvs” because that is encoded in the files in the CVS control directory. OK. Let’s edit index˙builder.c in local directory ../cvs/campbell/indexing/src/index and run update again. The “M index_builder.c” status indicates that the local version of index_builder.c has changed.

OK. Lets lets commit our new changes to index˙builder.c to the repository - for example Alan might need my new file for his build. When I issue a “cvs commit” I enter into an editor (export CVSEDITOR=emacs - but this in our bashrc) which is vi by default unless you change it. CVS present a log for you to fill in -which I write “ Made changes to #include files in index˙builder.c - ATC” and exit and type continue. The cvs tells me that the <--  index_builder.c index˙build has been committed and has a new version new revision: 1.2.

Other useful commands are cvs log and cvs diff. Notice that the index˙builder.c status reflects the changes we have made.

Finally, cvs diff is useful for seeing if there is any difference in the tree. No differences are detected.