In a single database environment, users can receive warnings about parallel versions at the time an object is checked out or checked in. In a distributed environment, the parallel version can be in a different database. Therefore, it might not be visible at the time it is checked out or checked in. It is not possible to disable parallel development in a distributed database environment.
During a receive operation, DCM checks for parallel versions on each new object received in the transfer package (except projects and products). The check occurs if the package was generated using the predefined Entire database transfer set or if that object was a history member. Objects that were not history members and where a user-defined transfer set was used are not checked for parallels. These objects are not checked for parallels because there is no guarantee that the history of the object is complete. A disjointed history can cause many false reports of parallels.
This behavior can be changed to include all received objects (except project and product objects) using the DCM setting Parallel Checking. Details of these parallel versions are included in any DCM receive email that is sent to the recipients defined in the transfer set. For details, see Modifying DCM settings
DCM can also send parallel email notifications directly to developers who own or created such parallel versions. If the Local Parallel Notification option in the transfer set of the source database is set, an email is sent (during parallel checking) to each user who is the owner of a parallel version. The email lists each received object and its parallel versions that relate to the user. Again, this feature applies only when using the Entire database transfer set or for objects that were history members of the transfer set.
The introductory text of the email is defined in the database_path/etc/dcm_local_parallel_intro.txt file. This text contains the keyword %database. When an email is sent, this keyword is replaced with the full path to the destination database.
If you are not using the Entire database transfer set and not using history members, then parallel checking on DCM receive is not performed. This might happen if you are using a user-defined transfer set and adding folders to the transfer set as a means of replicating tasks for a release. In such cases, perform separate checks for parallels on a regular basis using conflict detection. Conflict detection is performed with the ccm conflicts command, or the Detect Membership Conflicts operation in Rational® Synergy.