3.3 Committing Changes to the Repository | Essential CVS (Essentials)

Files are edited in the sandbox, but changes to the sandbox have no effect on the repository until they are committed. The cvs commit command uploads changes from the sandbox to the repository. After determining which files need to be changed in the repository, cvs commit opens an editor and expects you to enter a log message.

Section 3.1.3 earlier in this chapter explains how to change the default editor.

The syntax of cvs commit is:

 cvs [   cvs-options   ] commit [   command-options   ] [   filename   ]

cvs commit has only a few options:

-l: Perform a local, nonrecursive commit operation on the current working directory only.
-R: Perform a recursive commit operation on all subdirectories, as well as the current directory (default).
-m message: Provide a log message.
-F filename: Provide a log message from the specified file.
-r revision: Set an updated revision number (not recommended for novice users).

Example 3-3 shows a typical cvs commit . The vertical ellipsis denotes the point at which CVS normally calls the editor. Example 3-4 shows the default text displayed in the editor and the log message for this commit.

Example 3-3. Using cvs commit

 /home/jenn/cvs/wizzard$  cvs commit  cvs commit: Examining . cvs commit: Examining doc cvs commit: Examining lib cvs commit: Examining man cvs commit: Examining src . . . RCS file: /var/lib/cvs/wizzard/src/main.c,v done Checking in src/main.c; /var/lib/cvs/wizzard/src/main.c,v  <--  main.c initial revision: 1.1 done RCS file: /var/lib/cvs/wizzard/src/wizzard.h,v done Checking in src/wizzard.h; /var/lib/cvs/wizzard/src/wizzard.h,v  <--  wizzard.h initial revision: 1.1 done /home/jenn/cvs/wizzard$

Example 3-4. Entering log messages for cvs commit

  Added main.c: parses parameters and calls functions in other files.   Added wizzard.h: defines compile-time global variables.  CVS: ------------------------------------------------------------------ CVS: Enter Log.  Lines beginning with `CVS:' are removed automatically CVS:  CVS: Committing in . CVS:  CVS: Added Files: CVS:  src/main.c src/wizzard.h  CVS: ------------------------------------------------------------------

By default, cvs commit operates recursively on the current working directory. It can also take files or directories as parameters and operate recursively them.

Use either of the following variations of cvs commit to avoid having to enter a message during the commit process:

 cvs commit -m   message

or:

 cvs commit -F   filename

Examples 3-3 and 3-4 show a recursive commit, which commits files not only in your current working directory, but also in all subdirectories. If you want to commit only the current working directory (sometimes called the local directory), use cvs commit -l .

Use cvs status or cvs update -n to find out which files need to be updated or committed.

3.3.1 Setting Revision Numbers

You can use the -r option of cvs commit to set every file in a project to a specific revision number. This option is not used often; if it is used, it's usually by the project lead. The option changes the head revision number of all files, regardless of whether they've changed in the sandbox. The revision number must be higher than any number currently in the repository, and it must be in the same format as the existing revision numbers for the files.

CVS developers recommend you use tags to track revisions, and leave the internal revision numbers as CVS sets them by default. Chapter 4 explains how to use tags.

3.3.2 When to Commit

If your changes will not affect anyone else, commit frequently. Commit every time you'd hate to have to redo your work. Frequent commits keep your work in a single place for backup. If you are working in a team, frequent commits and updates reduce the chance of having to do a major, difficult merge.

If your changes will affect others, especially in a way that risks breaking the build, commit every time the effect will be negligible. For example, run a test-compile before lunch and before you leave, and commit if it compiles.

Don't ever work for long without committing. If a full day's work doesn't compile, wrap comment tags around your changes and commit the commented-out code or consider committing to a branch. Always speak to your project manager before branching.

Your project manager may have a commit strategy; if so, follow that. Chapter 7 discusses commit strategies in more detail.

Top