2.7. Committing Changes
Changes to your sandbox files are not synchronized with the repository until you run the cvs commit command. This command is best run from the root directory of your sandbox, and it must be run from within the sandbox.
Commit to the repository frequently. Rules of thumb for when to commit include "every time the code compiles cleanly" and "every day before lunch and before you leave." Speak to your project manager about the preferred working style, or read Chapter 7 for ideas.
When you commit, CVS examines each directory and subdirectory under the current working directory. It searches for files that it is tracking that have changed, and commits all changes to the repository. See Example 2-12 for an example of committing files. Remember that the repository path is stored in the sandbox, so you don't need to specify the path explicitly in your cvs commit command.
Example 2-12. Committing files
If your repository is not on the local machine and your repository server doesn't have your SSH public key, CVS asks for a password for the remote machine. If the server has the public key, your SSH client can use the private key to authenticate you. It's much easier to use CVS if the server has the public key.
Keeping a public key on the server is a security decision: it's much more convenient to use CVS if you don't have to keep typing in your password, but it also means that if an intruder has access to your shell, he can gain access to the data stored in the repository. I keep my desktop's public key on the server, but not my laptop's. It's always possible that I'll lose my laptop, so I don't want it to have password-free access into our network. The desktop computer is a little bit harder to lose.
If any files have been changed, CVS opens an editor to allow you to record a change message. By default, the editor is vi, just as when importing a project. Chapter 3 gives instructions on changing your editor.
I strongly recommend meaningful change notes. If you're trying to do a rollback and all you have are messages that say "fixed a few bugs," you won't know which revision to roll back to. See Example 2-13 for an example of a good change note.
Example 2-13. Enter a commit message
After you exit the editor, CVS completes the commit, displaying messages similar to those in Example 2-14.
Example 2-14. Completing the commit
Figure 2-7 shows the same commit in gCVS.
Figure 2-7. Committing files in gCVS
If a revision in the repository is more recent than the revision the sandbox was based on, cvs commit fails. Use the cvs update command to merge the changed files; resolve the conflict as shown in the next section, "Updating Sandboxes," then run cvs commit again. Example 2-15 shows the response to a failed commit.
Example 2-15. Failed commit response