要解决这些问题,您可以执行以下一个或多个操作:
使用“成员资格冲突”对话框检查项目成员及其项目更新特性之间的冲突。 一般来说,您将在更新之后执行此过程以查看存在冲突的位置。查看成员资格冲突的最佳时间是在更新完成后,因为项目成员那时已经知道您的项目最新特性。
冲突消息定义
下面的表以及表后面的冲突检测说明使用以下定义:
包含了与某个任务关联的对象,而该任务未指定为包含在项目中。
未包含与某个任务关联的对象,而该任务指定为包含在项目中。
对象的任务关系与预计不符(例如,没有任何任务与对象相关联,或者多个任务与对象相关联)。
冲突消息 | 缺省情况下是否显示冲突? | 描述 |
---|---|---|
冲突类别:多余更改 | ||
无任务 | 是 | 此项目中隐式包含对象版本,但未与任何任务相关联。 (不能显式包含它,因为这需要在项目更新特性中包含其任务。) |
隐式包含 | 是 | 未显式指定对象版本,但它包含在项目中。 任务未显式包含在任务中。 |
是否通过“使用”操作包含? | 是 | 未显式指定对象版本(也没有隐式要求),更新将不选择它。 |
显式对象中的隐式任务 | 是 | 任务的关联对象包含多个已分配的任务。至少任务的一个相关对象是显式(即包含在项目更新特性中),但此任务并非显式。 |
冲突类别:丢失更改 | ||
显式指定,但未包含 | 是 | 任务由项目显式指定,但未包含。 |
显式指定但不包含 - 更新 | 是 | 项目中显式指定了对象版本,但该对象版本是该对象当前所选版本的后继。 任务由项目显式指定,但未包含。 |
隐式要求,但未包含 | 是 | 隐式要求任务,但该任务未包含在项目中。 |
隐式要求,但未包含 - 更新 | 是 | 隐式要求对象版本,但未包括在项目中。它是当前所选对象版本的后继。 |
由多个任务隐式要求 - 最新 | 是 | 隐式请求对象版本,因为当项目中的另一个对象与多个任务关联时,它与显式包括的某个任务关联。 冲突中的对象版本未包括在项目中,但它是当前位于项目中的对象版本的后继。 |
冲突类别:其他 | ||
多个任务 | 否 | 对象版本包含此项目中,但是对象版本与多个任务相关联。 |
隐式要求,但在基线之前 | 否 | 隐式要求对象版本,但对象版本是基线的先行作业。 (这不是一个冲突,因为已将其显式包含,但它可能表示一个流程问题。) |
显式指定,但在基线之前 | 否 | 项目上显式指定对象版本,但该对象版本是基线的先行作业。(这不是一个冲突,因为已将其显式包含,但它可能表示一个流程问题。) |
显式指定,但对象未在项目中 | 否 | 项目上显式指定对象版本,但对象的版本均未在项目中。这可能是正常现象,因为整个项目层次结构共享同一个项目更新特性。 |
隐式请求,但对象不在项目中 | 否 | 通过项目中包含的任务隐式请求对象版本,但对象的任何版本均不在项目中。这可能是正常现象,因为整个项目层次结构共享同一个项目更新特性。 |
冲突类别:并行更改 | ||
隐式要求,但未包括 - 并行 | 是 | 隐式要求对象版本,但是该对象版本未包括在项目中。它与当前所选版本是并行的,可能需要合并。 |
多个项目隐式要求 - 并行 | 是 | 隐式请求对象版本,因为当项目中的另一个对象与多个任务关联时,它与显式包括的某个任务关联。 冲突中的对象版本不包括在项目中,但它是项目中当前对象版本的并行版本。 |
显式指定,但未包含 - 并行 | 是 | 项目显式指定对象版本,但该对象版本未包含在项目中。它与当前版本是并行的,可能需要合并。 |
冲突类别:错误任务 | ||
显式包含了已排除的任务 | 是 | 项目的项目分组集中包含了某个已排除的任务。 |
隐式包含排除的任务 | 是 | 排除的任务隐式包括在项目的项目分组集中。 |
未包含已完成的修订任务 | 是 | 项目的项目分组集中包括错误任务,但不包括 completed 的正确任务。 |
未包含已分配的修订任务 | 否 | 项目的项目分组集中包括错误任务,但未包含 task_assigned 的正确任务。 |
未包含任务已修订的任务 | 是 | 项目的项目分组集中不包括错误任务,但包括正确任务。 |
任务和对象关系
任务和一组对象版本之间可以存在某种关系。您可以将一组对象版本与某个任务相关联,从而表示一起使用这些对象版本,而且这些对象版本依赖于相互的变更。如果项目仅包括与任务关联的某些更改,那么您的项目构建可能失败,或出现更糟的情况,不能正确运行。
例如,如果您更改函数特征符,那么必须更新调用该函数的每个其他程序,以更改此特征符。 您必须在项目中同时包括所有这些更改,或不包括任何这些更改。
对象历史记录关系
任务包含历史记录关系,但与对象的历史记录关系有所不同。对象历史记录一般用数字连续表示。 任务历史记录仅仅是一个基于关联的文件历史记录关系的概念性关系。 完成更改需要使用任务组文件,因此任务历史记录关系将使当前的更改集合依赖于先前的更改集合。
main.c 文件包含 5 个版本。每个版本都与不同的任务相关联。(对象版本下面显示与每个版本关联的任务编号。)
Rational® Synergy 将某个对包含更改的对象版本的更改视为对其所有先行作业对象版本的更改。因此,在本示例中,认为版本 3 包含对版本 2 和版本 1 中的更改。
例如,如果更改版本 2 中的函数特征符,那么版本 3、版本 4 以及后面的每个版本都将包含该特征符更改。 更改放置在每个对象版本的上层。即使是除去另一个更改部分内容的更改也放置在其历史记录版本的上层。但是,main.c-3 中的更改仅适用于 main.c-2,因为更改是针对 main.c-3 执行的。
任务依赖关系
此外,因为版本 3 包含版本 1 和版本 2 中的更改,因此版本 3 的关联任务取决于版本 1 和版本 2 的关联任务。在本示例中,任务 58 依赖于任务 23 和任务 14。
显式指定的更新特性
请考虑包含 main.c-4 的项目 myproj-sue。
如果某个任务是项目的项目分组集的成员,那么项目显式指定包括与该任务关联的对象。例如,如果更新特性 myproj-sue 包括任务 72 和任务 23,那么它将显式指定包括与任务 72 和 23 关联的对象版本。 在上一个图中,如果项目已经显式指定任务 72 和任务 23,那么它还显式指定对象版本 main.c-4 和 main.c-2。
切记,main.c-4 包含 main.c-2 中的更改,而任务 72 取决于任务 23。
更新项目时,显式指定的对象版本就是其候选项。 更新将选择最合适的候选项(一般是最新的更新)。因此在本示例中,myproj-sue 将使用任务 72 和任务 23 来确定候选项列表:main.c-4 和 main.c-2。 它将选择 main.c-4 为最新的候选项。因此,项目将同时包括 main.c-4 和 main.c-2 的更改。同样地,它将包含任务 72 和任务 23 的更改。
隐式指定的更新特性
因为项目 myproj-sue 包含 main.c-4,所以它包含显式指定了项目更新特性的任务 72。 它还依赖于 main.c-3,因为 main.c-3 是 main.c-4 的先行作业。 它还依赖于与 main.c-3 关联的任务:任务 58。
但是,如果更新特性 myproj-sue 中未显式指定任务 58(继而未指定 main.c-3),但通过其历史记录关系包含更改,那么项目中将隐式指定任务和对象。与隐式指定的任务关联的对象不自动包括在项目中。
冲突
假设您准备发布项目。您指定此发布标识包含任务 72 和任务 23,但未指定任务 58。构建后,任务 58 将包括在应用程序中。Rational Synergy 可能警告您包含了未请求的任务。这称为冲突。
冲突有多种不同的类型。如果手动使用项目中的 main.c-5,但项目更新特性未显式指定任务 86,那么显式指定的其他任务都不依赖于任务 86,这将是另一种冲突类型。 Rational Synergy 可以警告您可能在项目中使用了某个对象版本,而不警告显式指定的任务。
一些冲突比其他冲突更加严重。
例如,您的团队可能决定在文件的单个版本中更改不止一个错误。 而且您的团队要求每个开发人员仅将一个任务与他们更改的每个对象版本进行关联。如果某个对象版本与多个任务相关联,那么您必须知晓,以便您向开发人员提醒这一需求。 尽管如此,这并不是一个严重的冲突,因为您准备发布的软件包含所有需要的更改。
更严重的冲突是不与任何任务关联的隐式包含的对象版本。
Rational Synergy 可以警告您这两种类型的冲突。
并行冲突
其中最重要的一种冲突检测是检测并行对象版本。
如果项目显式指定某个更改但不包含该更改,那么这就是一个严重的冲突。 例如,请考虑如下情况:两个并行对象与两个不同的任务相关联,而且两个任务均为显式指定。在本示例中,假设 myproj-sue 包含 bar.c-3。 bar.c 对象包含下图所示的历史记录关系和任务关联。
myproj-sue 项目更新特性指定包括任务 58 和任务 86。您的项目仅包括与任务 58 关联的 bar.c-3。 它还可以包括与任务 86 关联的 bar.c-2.1,因为这是一个并行分支。 bar.c 的所有版本都不包含您请求的更改。这是一个严重冲突,因为项目中缺少必需的对象版本。
并行冲突可能意味着丢失更改,但是也存在其他类型的丢失更改。
丢失更改
试想一下,如果手动将 bar.c-2.1 包括在 myproj-sue 项目中,那么将会发生什么状况。虽然显式指定,但任务 58 和任务 86 的更改仍将丢失,因为它们比项目中当前的对象版本要新。
显式指定了该更改,但丢失。如果在项目更新特性包括的任务中查找,那么可能还将注意到丢失的更改。其他冲突类型更难以检测。
如果刷新 myproj-sue 上的项目更新特性以包括任务 86 和 36(而非任务 86 和 58),那么不再显式指定任务 58。任务 86 与 main.c-5 关联,而其先行作业则与任务 72 关联的 main.c-4 相关。因此任务 86 隐式包括任务 72。如果项目包括 main.c-5,后者包含两个更改,那么没有任何问题。但 bar.c 会怎样呢? 将显式指定 bar.c-2.1,因为它与任务 86 关联,同时隐式指定 bar.c-3,因为它与任务 58 关联(在项目中隐式指定)。 因此,再一次没有 bar.c 的任何版本将包含项目请求的所有更改。
大规模冲突检测
现在请考虑一个包含数百个对象成员的项目,其中每个对象成员在其历史记录中包含多个版本,以及由数百个任务组成的发布标识。不管您的团队有多仔细,项目越大,出错的机会就越大。常见错误包括由于并行开发(忘记合并)或人为错误(忘记对象/任务关联)而造成的冲突。 解决方法是在构建之前找出错误并予以纠正。 Rational Synergy 可以检测大型项目上的冲突,从而您的团队可以在冲突成为问题(例如推迟构建)之前解决掉。
Rational Synergy 可以根据历史记录关系和任务关系检测 24 种不同的冲突。 可能还存在其他冲突,但并不严重,并且缺省情况下不显示,以便用户可以集中关注影响软件完整性的冲突。但是,如果想要更改缺省情况下显示的冲突,您的 CM 管理员可以通过 conflict_parameters 模型属性来执行此操作。
将会分析项目以确定是否存在任何冲突,然后显示这些冲突。
根据项目大小和特征,冲突检测可能非常费时,因此需要计划显示冲突的最佳时间。构建管理员通常在每次更新构建管理项目后显示冲突。如果开发人员怀疑项目包含并行版本或其他会引发问题的冲突,那么他们可能想要显示冲突。
要查找项目,请参阅查找对象。