Module Maintenance

Staying Up to Date

A single project in CVS can support any number of working copies, which allows 

multiple developers to work on a project simultaneously. When you make changes 

in one working copy and commit them, your fellow developers will need to perform a 

cvs update to synchronize their working copies with the repository. For example, if 

I performed the cvs add INSTALL operation previously in one working copy, then 

my coworker Jesse would need to run cvs update in his working copy to get the new 

file as follows:

$ cvs  q update  d

U INSTALL

The  q ( quiet ) option suppresses printing all the files and directories in the 

project. The  d option isn't strictly necessary in this case, but it's a good option to 

use when updating a project directory it allows CVS to create new directories 

that have been added to the project since the last update.

Time Travel

Most often you'll be working on the most recent version of your module, and CVS 

makes that very convenient. Other times you'll need to travel back in time, and 

that's when CVS becomes nearly indispensable. For example, imagine that Bob 

Dobbs sends me a patch to Data::Counter that adds a new feature. I apply the 

patch and commit the change:

$ cvs commit  m "New feature from Bob Dobbs" Counter.pm

Checking in Counter.pm;

/home/sam/cvsroot/Data Counter/Counter.pm,v  <    Counter.pm

new revision: 1.3; previous revision: 1.2

done

Time passes, and a few weeks later I start having trouble with the function that 

Bob patched. In order to determine if Bob's patch is to blame, I need to roll back to 

the version before the patch and try my test case. Now, one option would be to dig 

out Bob's patch and reverse it using patch  R, but CVS offers an easier solution. 

Using cvs update with the  r argument, you can update a file to an arbitrary 

revision. For example, this command brings Counter.pm back to the state it was in 

before Bob's patch:

$ cvs update  r 1.2 Counter.pm

U Counter.pm

15

157

7