Problems Associated With Propagating Changes
Many of the problems associated with propagating changes involve moved and renamed members, and moved subprojects. The problems fall into two main categories:
• Locating the corresponding member or subproject in the target when the member or subproject in the source has been moved or renamed
• Processing entries in the best order when multiple move operations have taken place (especially important with nested move subproject operations)
Locating Corresponding Member or Subproject in Target Source Member or Project Was Moved or Renamed
The following is a general description of the process Integrity Lifecycle Manager uses to locate the target project for a given change package entry:
1. Given the path to the source project that owns the change package entry, Integrity Lifecycle Manager determines if the target project (which is a different variant of this project) already exists in the target hierarchy. If the target project exists, use it as the target.
2. If the target project does not exist, see if the source project is still visible (registered); in other words, the source project has not been moved or dropped. If the source project does exist, create the corresponding variant subproject in the target hierarchy.
3. If the source project does not exist, it may be because it was moved. Use the configuration path encoded in the change package entry to try to find the source project’s location after the move. If Integrity Lifecycle Manager finds the source project, find or create the corresponding project in the target project tree.
4. If the previous attempts fail, no further attempts are made. Integrity Lifecycle Manager cannot find the target project to propagate the changes to. You must manually perform the propagation.
|
|
This section is a major simplification of the logic used by Integrity Lifecycle Manager, and is only intended to provide a general idea of the process. There are many details omitted that are beyond the scope of this documentation.
|
5. Once the target project has been located, Integrity Lifecycle Manager attempts to find the target member or subproject within that target project that the changes need to be propagated to.
For all operations other than move and rename, Integrity Lifecycle Manager looks for the member (or subproject) in the target project tree with the same name as the member (or subproject) in the source project tree (verifying that the member or project has the same backing archive or project). If Integrity Lifecycle Manager finds the corresponding target, it updates it accordingly. Otherwise Integrity Lifecycle Manager adds the member (or subproject) to the target project tree (pointing to the same backing archive or project).
For moves and rename operations, Integrity Lifecycle Manager server follows the same basic process as other operations, but with the addition that Integrity Lifecycle Manager server knows both the "from" and "to" names for the move or rename operation, so it is more intelligent in searching for the target.
Processing Entries in Best Order When Multiple Move Operations Exist
As previously stated, Integrity Lifecycle Manager generally examines entries within a bucket in chronological order, with earlier entries processed before later ones.
|
|
Integrity Lifecycle Manager is not propagating changes sequentially. It is examining them sequentially to produce the single net result for that bucket.
The net results are grouped by the parent project that they belong to and the corresponding operations are performed on each parent project as a single bulk operation on the Integrity Lifecycle Manager server , as whenever possible.
In cases where operations are being propagated across multiple projects (or subprojects), the Integrity Lifecycle Manager server uses an optimal ordering in which to process each project’s corresponding bulk operations. As of Integrity 2009, the configuration path information is used to order the processing of the projects (or subprojects) so that if they exist in a hierarchy parent projects are processed before their child subprojects. This has been empirically shown to provide better results in situations where complex subproject refactoring scenarios (such as multiple nested subproject moves) are being propagated.
|
