The cvs update command checks your sandbox against the repository and downloads any changed files to the sandbox. It complements the cvs commit command, which uploads changes from the sandbox to the repository. Use the -d command option to download new directories as well. Example 2-16 shows the use of cvs update .
$ cvs update -d cvs update: Updating . U file2 cvs update: Updating directory $ ls CVS directory file1 file2
As with committing, you should not have to specify the repository; it should be stored in the special CVS subdirectory in the sandbox. You must run cvs update from within the sandbox, and it is best to run it from the root directory of the sandbox to ensure that it checks all the subdirectories.
Note that -d means two different things, depending on where it is in the command. Recall that CVS commands take the form:
cvs [ cvs-options ] command [ command-options ]
As a CVS option, -d defines the directory path . As a command option to the update command, -d downloads directories and files. This is explained more in Chapter 3.
As the update command runs, it generates a list of files that are modified. To the immediate left of each filename, you will see a single uppercase letter. Those letters report the status of each file listed, and they have the following meanings:
Updated successfully. A newer version in the repository has replaced your sandbox version.
Marked for addition but not yet added to the repository (need to run a cvs commit ).
Marked for removal but not yet removed from the repository (need to run a cvs commit ).
Modified in your working directory. The file in the sandbox is more recent than the repository version or the sandbox and the repository both had changes that the system could safely merge into your sandbox copy (need to run a cvs commit ).
There was a conflict between the repository copy and your copy. The conflict requires human intervention.
The file is in your working directory but not in the repository. CVS doesn't know what to do with it.
The A, R, and M codes mean that your sandbox contains changes that are not in the repository and it would be a good idea to run a cvs commit .
If CVS can't merge a modified file successfully with the copy in the repository, it announces the conflict in the output of cvs update , as shown in Example 2-17.
cvs/example$ cvs update cvs server: Updating . RCS file: /var/lib/cvsroot/example/file1,v retrieving revision 1.3 retrieving revision 1.4 Merging differences between 1.3 and 1.4 into file1 rcsmerge: warning: conflicts during merge cvs server: conflicts found in file1 C file1
CVS automatically merges files when the changes are on different lines. If a line in the repository copy is different from the corresponding line in the sandbox copy, CVS reports a conflict and creates a file with the two revisions of the line surrounded by special marks, as shown in Example 2-18.
<<<<<<<file2 This line came from the sandbox. = = = = = = = This line came from the repository.. >>>>>>> 1.4
The contents of the original file are stored in .#file.revision in the file's working directory, and the results of the merge are stored as the original filename. Search for these marks in the file with the original name , edit the file, then commit the changed file to the repository.