![]() |
Chapter 3 | ![]() |
checkout
To make a local copy of a module's files from the repository execute 'cvs checkout' where module is an entry in your modules file (see below). This will create a sub-directory and populate it with the files from the repository for you to work on.
update
To update your copy of a module with any changes from the central repository, execute 'cvs update' from within the directory of the module you're updating. This will tell you which files have been updated (their names are displayed with a U before them), and which have been modified by you and not yet committed (preceded by an M). It can be that when you do an update, the changes in the central copy clash with changes you have made in your own copy. You will be warned of any files that contain differences which cannot be automatically resolved, by a preceding C. For example:
> cvs update C act.wizard.c C act.informative.c M act.social.c interpreter.c U spells.c
Inside the files with conflicts, the areas of interest will be marked in the file surrounded with text strings of greater than or lesser than signs, as such: <<<< and >>>>. You have to resolve these clashes in your copy by hand. If you perform a CVS update, and there are conflicts, your original v ersion of the file is automatically saved as `.#file.version'. That way, if you feel you have messed up a file and wish to have CVS forget about your changes and go back to the version from the repository, delete the file and do an cvs update. CVS will announce that the file has been "lost" and will give you a fresh copy.There's a bit more on this below, in the example section.
commit
When you think your files are ready to be merged back into the repository for the rest of your developers to see, execute 'cvs commit'. You will be put in an editor to make a message that describes the changes that you have made (for future reference). Your changes will then be added to the central copy. When you do a commit, if you haven't updated to the most recent version of the files, CVS tells you this; then you have to first update, resolve any possible clashes, and then redo the commit.add and remove
It can be that the changes you want to make involve a completely new file, or removing an existing one. The commands to use here are:log
- cvs add
- cvs remove
You still have to do a commit after these commands to make the additions and removes actually take affect. You may make any number of new files in your copy of the repository, but they will not be committed to the central copy unless you do a 'cvs add'.
CVS remove does not actually remove the files from the repository. It only removes them from the "current list" and puts the files in the CVS attic. When another person checks out the module in the future they will not get the files that were removed, nor will the files in their directory automatically be removed!. But if you ask for older versions that had the file before it was removed, the file will be checked out of the attic. Sounds confusing, but it's not too bad.
Best Programming Practice says to do a fresh checkout in an empty directory each time you start a new project.
To see the commit messages for files, and who made them, use:
> cvs log ['filename(s)']
diff
To see the differences between your version of the files and the version in the repository do:Whew. The ones you'll use most often are update and commit.
> cvs diff ['filename(s)']
![]() |
Index | ![]() |
3.2.5 Checking Out Modules From CVS | 3.2.7 CVS in Action |