During an update, the output is written to the session log file and the Messages dialog box. However, reading the update results in this log file can be cumbersome because all other messages also are written to this file.
You can redirect the ccm_client.log (user interface log) file to point to a location other than your Windows profile directory (Windows users) or ccmlog directory (UNIX users). Set the ccm.user.properties key in the ccm.user.properties file as shown in the next steps.
For Windows users, the file is called ccm.user.properties and is located in your Windows profile directory.
For UNIX users, the file is called .ccm.user.properties and is located in your home directory.
* To redirect a log file to C:\cmsynergy\synint\bob, do the following:
user.default.logfile=
C:\\cmsynergy\\synint\\bob\\ccm_client.log
* To rename a log file (typically when working in multiple databases), for a database named int, do the following:
user.default.logfile=
C:\\cmsynergy\\bob\\ccm_client_int.log
When using the ccm.user.properties key, you must use the complete path and file name.
Additionally, users must enter Windows paths using double backslashes.
Read the update results after every update/build cycle to look for problems. At the end of the update messages, a summary is written in the Messages dialog box or output log describing the outcome of the update. However, make a habit of reviewing the logs to read detailed reports of update failures.
Additionally, a successful build does not always mean that the software is configured correctly. Reviewing the update results is a good way to find errors in the configuration: The wrong version of an object or project, changes that were not merged, incorrect selection property settings, and so on. Here are some things to look for.
Assume that you build from the CLI and you set the reconfigure_parallel_check option. If a given set of update candidates contains parallel scoring, you receive a warning message like the following in your ccm_ui.log.
Warning: Parallel versions selected by selection
rules, latest create time will be used:
save.c-3
save.c-2.1.1
Check that the history of the object called out in the parallel warning message was merged. If not, your build is missing part of a change. Notify the developers involved to merge the parallel versions.
For information about how to check for parallel versions when building from the CLI, see All build managers for information about selecting parallel notifications during update.
Your build management project hierarchy must stay together as a unit. If update properties (release, platform, and so on) are set incorrectly, update might select a different version of a subproject. Check for messages such as:
Subproject editor-int_3.0 replaces editor-int_2.1 under toolkit-2:dir:1
If you find any messages about replaced projects, investigate the project versions; check their update properties to verify that they are correct.
By default, a directory entry is left empty if there are no candidates for it. If you find any, look for reasons for the occurrence, such as a task with a wrong release value. Look for messages, such as:
2 directory entries were left empty because they had no candidates.
Empty directory entries are not always an error. For example, directory entries might be left empty if you build products on multiple platforms within a single directory. A shared library might be named mylibrary.so on Solaris and mylibrary.dll on Windows. Assume that you control both products in the same directory, but use the directory in two parallel projects for the two platforms. You get an empty directory entry for the Solaris library in the Windows project, and vice versa.
A developer can customize a makefile with specific environment settings, then accidentally check in the custom makefile. If any makefiles are replaced during the update process, review the new versions of the makefiles. Ensure that the changes are appropriate for your build environment. Look for messages, such as:
'makefile-6:makefile:3' replaces 'makefile-5:makefile:3' under 'editor-2:dir:1'
If your project has conflicts, use Sync Work Area to resolve work area conflicts, then update again. Look for messages, such as:
Unable to update membership of project ccm_client,td_7.1 with InteractiveProcessCreator.java,21:java:J#1 due to work area conflicts.
If an older object version replaces a newer one during the update process, perform a show conflicts operation to help pare down possible problems. Look for messages, such as the following:
'main.c-2:csrc:3' replaces main.c-3:csrc:3' under 'toolkit-4:dir:1'
Additionally, look at the task that the newer object version is associated with and look at the process rules for the project. The compare might show why the older version replaced the newer version. The compare might also show differences in the process rules that are causing the task to add the older object version.
If you see any problems and cannot understand them, run update again with verbose messages set to receive detailed update results in your output log. (Set Show verbose messages in the Options dialog box Actions tab, in the Update option.)
The following sections describe update in greater detail: