Assignment 8

Due Dec 4th at 4:00 p.m.

Implement and test your design as specified in your design document. Each designed and implemented module will be expected to conform to coding standards. Each module will come with at least one test driver and instructions (in a readme file) for running tests. Please talk to me anytime and I will help you figure out how to properly test your modules. I expect that the test driver for your module along with the readme for that module will be in a test subdirectory under your module directory. A top level project readme should describe all modules, their locations (in your project directory structure) and any deviations from the default test driver location.

Assume that you have already checked out your group's project, worked on your modules, and made changes. Your objective is to not break the system when committing your changes. Your group's cvs commit policy (to be followed by every group member) to commit a member's changes to the group's cvs repository, should be

  1. Do a cvs update in your current project directory. This will make your copy of the project files current with the central group repository.
  2. Check that your updated copy works. Run your tests. This will make sure that your files are compatible with other members' commits.
  3. Quickly commit your changes.
  4. Do a complete fresh checkout of the project from an empty directory. Compile the project and run your module tests.
Adhering to this policy will minimize system breakage. Starting with a working skeleton, the idea is to make sure that as the system gets fleshed out it never breaks. The usual industrial policy is to compile and test the complete system every evening (nightly builds) -- if the system is broken (it doesn't pass the system tests), you work until it is fixed. Few people commit big changes late in the day.

Note that our cvs repository is backed up everynight, thus you will never lose anything you commit. Note also that if the flow of control never reaches code that you committed, the system will not break. It follows that you can commit non-working code and not break the system. You may want to do such a thing to share code with another group member or to ensure that your work gets backed up.

Assuming that each module is "owned" by its designer and implementer, you should only need to make changes in files owned by you. In the real-world, co-workers may not take kindly to you fixing their "bugs." Especially, if it wasn't a bug at all, but an integration problem in your implementation.

I will check out your project snapshot at 4:00 p.m. on December 4 from your group's cvs repository. You need not hand in anything in class.

If you have any questions, comments, or ideas, come and talk to me. Good Luck.

Sushil Louis
Last modified: Wed Nov 21 09:21:42 PST 2001