< Zurück | Inhalt | Weiter >

8.2.3 Normal Use

The typical use of CVS occurs after you’ve made some changes to your source code. At some point, typically after the code compiles cleanly or after the changes have been tested to some extent, you will want to commit your changes to the CVS repository. When you commit one or more files, they become the latest version, the version that others get when they checkout or update the module. To say it another way, when you commit, you make those changes a permanent part of the source repository, available to others.

You can commit a single file at a time, like this:


$ cvs commit Account.java


Or you can commit several files at a time, like this:


$ cvs commit Account.java User.java Xyz.java


Or you can commit all the changes from a certain point in the filesystem hierarchy (e.g., the current directory) on down, like this:


$ cvs commit


(Specifying no files implies the current directory. You can also name a directory explicitly.)

When you commit changes, CVS wants you to provide a bit of commen- tary to explain what you’ve changed, to say something about this new version. The comment can be supplied on the command line, with the -m option:


$ cvs commit -m "bug fix"


If you don’t provide the -m parameter and its argument, CVS will invoke your favorite editor (as specified in the environment variable CVSEDITOR or VISUAL or else EDITOR, in that order of precedence). The default, on Linux systems, is to invoke vi (see Figure 8.2). In the editor, you can type one or more lines of text; when you exit, the commit will continue to completion.



image


Figure 8.2 CVS asking for commentary as part of a commit



NOTE

If you quit the editor without writing your changes (in vi, that would be :q!) then CVS will ask if you want to abort the entire commit. If you choose to abort, no changes will be made to the repository. You’ll be right back to where you were just before typing the cvs commit command.


image

You will be able to see the comments associated with each version of the file using the cvs log command (see Section 8.2.6).

As you will want to provide brief but meaningful descriptions in these comments, it may be helpful to remind yourself what in fact has changed. You can see the differences between the version that you checked out and the file as it stands today by using the cvs diff command:


$ cvs diff Account.java


Here, as in commit, you can name one or more files, or even a directory. CVS will display what lines you’ve added, modified, or removed in each file.


image

Example 8.1 Sample output from cvs diff

$ cvs diff Account.java albing@cvs.multitool.net's password: Index: Account.java

===================================================================

RCS file: /usr/lib/cvs/cvsroot/JavaAppDevLinux/majorApp/net/multitool/core/ Account.java,v

retrieving revision 1.10 diff -r1.10 Account.java 31d30

< this.parent = null; 66a66

> * returns an iterator 93c92

< children.put(acct, name);

---

> children.put(name, acct);

$


image


In Example 8.1, CVS has found three differences—one line being re- moved, one line being added, and one line being changed. The < precedes lines from the repository version, and the > precedes lines from the new, that is, changed, version. The 31d30 shows the line numbers from both versions, sep- arated by a single character to indicate what difference action is being described: a for adding lines, d for deleting lines, and c for lines that change.

A typical work sequence might go something like this:

1. Edit some files.

2. cvs diff those files.

3. cvs commit those files.

4. Go to 1.

The cvs diff command is also quite useful for finding out what changed between some previous version of a file and the current version:


$ cvs diff -r 1.15 Account.java


or between two different previous versions:


$ cvs diff -r 1.12 -r 1.15 Account.java


or since a certain date:


$ cvs diff -D 06-Sep-03 Account.java