There are several important things to keep in mind in any CVS-based
project:
Although CVS can merge changes to the same file from two different
teammates, it is usually better if different people are working on
different files at a time.
Whenever possible, test your changes before committing them.
Do a CVS update before each coding session.
To avoid errors it is best to do another update before committing
changes.
Developmental Practices
You are working with other people.
Communicate with them to ensure that what you are doing is compatible
with what they are doing.
Do not change the interface on components without consulting with the
team.
As in any project, it is best to do some planning on changes so that
you can break them up into small increments.
Do regression testing.
Regression testing means running a sequence of tests that
grows as a project evolves.
It is impoirtant to ensure that old functionality is retained by
running old tests as well as new ones.
When possible use pairs programming.
In this technique, one person writes or modifies code and
explains what they are doing and why.
The other person challenges any explanations they don't understand or
don't agree with.
This might sound inefficient, but when done right it can save a lot of
debugging time.
Documentation
Keep project documentation up to date.
When you do a CVS commit, briefly describe what you did in the commit
message.
In the message you should indicate who participated in the changes.
When you do pairs programming both people's names should appear in the
commit message.
Keep a log of team meetings.
You don't have to log details of discussions.
You just need to record who attended, decisions about what you will
try to do and who is going to do it.
Since there is only one team, you can just have someone email meeting
logs to the class alias: cs5741-1-f2009@d.umn.edu.