Updating and Committing Files in a Multiuser Project

After your mulituser project has been successfully imported into the repository, you may checkout the source base for the project to begin hacking away on your own working copy. If you edit a file in this project called ``frob.c'' and wish to see if any other changes have been made to the source base before committing your own, you may issue a ``cvs update'' command to grab the latest changes:

mbland@defender
/home/student/mbland/projects/class_proj -> cvs update .
cvs update: Updating .
U empire.c
RCS file:/home/student/mbland/cvsroot/cpsc426/class_proj/frob.c,v
retrieving revision 1.3
retrieving revision 1.4
Merging differences between 1.3 and 1.4 into frob.c
M frob.c

The output codes from the cvs update command translate to the following:

• U means that someone else has updated that file, and the changes have been automatically merged into your working copy; sometimes this will be a ``P'', but will mean essentially the same thing

• RCS file ... Merging differences... indicates that someone else has modified the same file you have, and their changes have been merged into your working copy; however, no textual conflicts were detected

• M indicates that you have made changes to the file which have not yet been committed to the repository

While CVS does not implement file locking, outright conflicts between revisions by different developers have been historically infrequent; see the CVS manual for a discussion of how this all works out⁴. Also refer to the document Introduction to CVS by Jim Blandy, located at the CVS website (http://www.cvshome.org/), for an example of how CVS handles direct textual conflicts.

After updating, rebuilding, and retesting your working copy of the source code, if you now wish to integrate your changes into the repository for all to see, you can do that by invoking the ``cvs commit'' function:

cvs commit -m ``Added magic grue detection function'' frob.c