Java Reference
In-Depth Information
The
Merge
tool is like a three-panel version of the diff tool you've already seen.
On the left is your local copy of the file before the merge, in a read-only editor
pane. On the right is the version that is checked in to
CVS
, also read-only. In the
middle is the merge result: an editable file that will become your local file when
you complete the merge. It starts with the contents of the file before you began
making any local changes.
Using the change tools previously discussed, you can apply changes from
either the left or right pane into the merge results file in the center. The
Apply
all non-conflicting changes
button on the toolbar lets you automatically accept
any changes that don't conflict with each other, allowing you to concentrate on
the conflicts. For each remaining conflict, you can decide to either take your
changes, take the other developer's changes, or edit the merge result file by hand
where neither set of changes can be applied verbatim.
Auditing changes
You can certainly track down who was responsible for checking in any particular
line of code by examining each revision of the file, but there is an easier way. The
CVS
| Annotate
command shows an annotated listing of the file. In the gutter
beside each line, you can see the version in which each line originated, the user
ID
of the person who committed that line, and the date that version was commit-
ted. An example is shown in figure 8.19. You can access annotated views of older
revisions of the file by bringing up the file's history view (
CVS
| Show History
),
selecting the old version, and then clicking the
Annotate
icon or selecting the
Annotate
option from its context menu.
This option is sometimes known as the
blame tool
, since it provides a con-
venient way to audit changes and discover exactly whom to blame for
problem in any given line of code.
NOTE
Figure 8.19 The CVS Annotate command shows you, for every line in the file, when
it was last updated and who performed the commit operation.
