Java™ Application Development on Linux - Dator

192Chapter 8Know What You Have: CVSOnce a repository has been set up for use by a project, each developerwould check out a copy of the source. Thereafter, the typical sequence for adeveloper would be:1. Edit.2. Test.3. Commit.4. Go to step 1.In some organizations, developers will commit and then test. Others willwant to only commit changes that have been tested. Which order you chooseis a policy decision by your project, not mandated by CVS.TIPWe recommend that you test before committing because once you have committedyour changes, they become available to all others developers. The morepeople are working together on a project, the more important it is to keep thesource base workable, that is, clean compiling at least, so others can keepworking.Sometimes the developer needs to do an update step before a commit.Such a step is used to integrate other developers’ changes into this developer’ssource. Sometimes this goes smoothly; other times it needs someadditional work.A simple scenario might help explain these steps, too.Two developers, Ti and Kwan, are working on project Doh. They alreadyhave a repository set up with all the source for project Doh. Each developer,on his/her own system, checks out a copy of the source (cvs checkout doh).Now let’s say that part of the source is a Java class file called Account.javaand it has had several changes made already, so Account.java is now atversion 1.7 in CVS.Let’s say that Ti finds a bug in Account.java and makes a change to fixthat problem. Ti checks in (commits) the changes to Account.java (cvscommit Account.java) so that the repository now contains Ti’s changes,which CVS keeps as version 1.8 of Account.java.All this time Kwan has been busy modifying Account.java (e.g., addinga new method). Remember that Kwan is working from the 1.7 version. When