On Wednesday of the second week of the project, the development server finally became available. Until now, the developers had been doing all work on their local desktop machines, and transferring files between one another for compiling and testing. This includes the initial spike tests as well as development of production code. One of the developers on the team is John Reynolds, who is a Java developer and has expertise in CVS. Michael asks John to set up their CVS repository, and to pair with Jeff so that Jeff can learn more about setting up CVS. Jeff in turn will be able to teach John more about using Ant. The two will work together to define the necessary targets in the buildfile to handle their CVS needs. Because Jeff has completed the unit testing targets for the buildfile, he begins adding some targets that they will definitely need: perform a CVS update and perform a clean build.
After the CVS repository is set up, the developers are able to add and commit their code to the repository, and begin controlling their code in CVS. Michael sets the requirement that code committed to CVS must compile and pass its unit tests.
No matter what the size of the development team is, version control plays an important role in the process. At one level, you can think of version control as a part of an automated backup process. Beyond that basic level, version control enables development team members to work in conjunction with each other, regress to earlier versions, and treat a group of files as a single unit. We believe that it's important at the outset to set up a version-control practice. Version control is one of those areas that isn't as interesting as architecture or design, and it can easily be neglected. This is exactly why we think it's important to set up such a system initially; that way, it isn't postponed or neglected entirely.