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 so that it points to a location other than your Windows profile directory (Windows users) or ccmlog directory (UNIX users). This is done by setting the ccm.user.properties key in your ccm.user.properties file as follows:
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
Note that when using the ccm.user.properties key, you must use the complete path and file name, as in the example above.
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, Rational Synergy writes a summary in the Messages dialog box or output log describing the success or failure of an 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.
If you build from the Rational Synergy CLI and you set the reconfigure_parallel_check option, if a given set of update candidates contains parallel scoring, you will receive a warning message similar to the following in your Rational Synergy Classic 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 the history of the object called out in the warning message to see if parallel versions that should have been merged were not. If so, your build is missing part of a change, and you should notify the developers involved that they need to merge the parallel versions.
For information on how to check for parallel versions when building from Rational Synergy or the Rational Synergy CLI, see s_c_bmg_all_bms.html#wp1016699__wp1016702
Your build management project hierarchy must stay together as a unit. If update properties (release, platform, etc.) are set incorrectly, update could 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, Rational Synergy leaves a directory entry empty if there are no candidates for it. If you find any, you might need to look for reasons for the occurrence, such as a task with a wrong release value. Look for messages, such as the following:
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. If you control both products in the same directory, but use that directory in two parallel projects for the two platforms, you will get an empty directory entry for the Solaris library in the Windows project, and vice versa.
A developer could customize a makefile with settings specific to his environment, then accidentally check in the custom makefile. If any makefiles are replaced during the update process, review the new versions of the makefiles to ensure that the changes are appropriate for your build environment. Look for messages, such as the following:
'makefile-6:makefile:3' replaces 'makefile-5:makefile:3' under 'editor-2:dir:1'
If your project has conflicts, you will need to use Sync Work Area to resolve work area conflicts, then update again. Look for messages, such as the following:
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:
'foo.c-2:csrc:3' replaces 'foo.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. Comparing these might tell why the older version replaced the newer version; it should show you some difference in the process rules that is causing the task to add the older object version.
If you see any of these problems and cannot figure out what happened, perform another update with verbose messages set to receive more detailed update results in your output log. (Set Show verbose messages in the Options dialog box Actions tab, in the Update option.)