用户帮助 > 在更改包中对工作单位进行分组 > “重新同步更改包”概述 > 将传播更改包与“重新同步更改包”一起使用
  
将传播更改包与“重新同步更改包”一起使用
您可以使用其他更改包来记录由“重新同步更改包”操作进行的所有成员更改。用于此用途的更改包称为传播更改包。
* 
即使管理员已将更改包设置为必要,您也不需要为“重新同步更改包”操作指定传播更改包。
您没有创建传播更改包,而是创建一个正常更改包,如果您在执行“重新同步更改包”操作期间指定此更改包,则会将传播信息记录在此更改包中。为了最大程度地控制隔离更改,建议您从空传播更改包开始。如果传播更改包不包含之前的条目,则只会添加那些与谈及的更改明确相关的条目。
系统会将执行的所有成员和子项目更改以及由于重新同步而传播的更改包填充到传播更改包中。您可以放弃不需要的成员更改,并将已解决的合并冲突添加至传播更改包。您也可以根据需要使用 Windchill RV&S 命令(例如“检出”、“移动”、“重命名”、“更新成员修订版本”或“创建子项目”),将条目添加至传播更改包。
完成所有更改后,便可以提交传播更改包以更新项目。
* 
您也可以提交传播更改包,而不更新成员修订版本;然后,构建管理员会在构建软件时应用传播更改包。
传播更改包中的条目会取代已重新同步的更改包中的对应条目。因此,如果您从分支执行合并,并且将结果检入到传播更改包中,则生成的修订版本会取代所列更改包(可能在分支上)中的任何条目。
使用传播更改包的优点
使用传播更改包可确保其他开发人员能够应用同一组更改包,并且无需重复运行“重新同步更改包”命令以及解决任何错误或合并冲突。
传播更改包也可以用来帮助构建管理员完成其工作。如果“应用更改包”操作失败,开发人员可以对同一更改包使用“重新同步更改包”命令,标识相关性和所需的合并,并且将所有必要的更改包括到单一传播包中。
借助传播更改包,您可在开发路径之间增量传播更改,具体方法是:重复使用“重新同步更改包”命令收集项目更改,而不是执行一个可能需要很长时间的大型“重新同步更改包”操作。
如果您使用传播更改包,已应用更改包所基于且已通过先前的“重新同步更改包”操作应用至项目的任何更改包都不会显示在回填列表中。您会收到一条有关已应用的更改包的警告消息。
请务必注意,虽然可以使用“重新同步更改包”来应用传播更改包,但不一定总是能获得可接受的结果。例如,如果错误修复位于现有项目成员中,则项目中会已经有该成员的存档。因此,“重新同步更改包”会在分支上添加已修改的成员。项目中可能不会接受此附加分支。
传播更改包使用示例
abcBusiness 公司有两个开发团队:
产品团队会为主要发布周期开发新功能和软件
维护开发团队会维护已发布的软件并解决客户识别的错误
产品团队 (PT) 会对主要开发路径实施新功能和设计。
维护开发团队 (MDT) 会处理 2.0 版的变型开发路径,并且修复新发布的产品中的任何问题。此团队的主要目标是制作出 2.0a 版的错误修复。MDT 的工作流程是:
客户报告了一个错误。
创建针对该错误的更改包,在本例中,它具有容器 ID 1204。启用工作流,会因此创建一个项并将该项与已创建的更改包关联。
指派一位 MDT 开发人员来解决问题。
该 MDT 开发人员会创建一个更改包。
该 MDT 开发人员会进行必要的更改并测试代码。
该 MDT 开发人员会将已修改的文件重新检入变型项目,从而确保文件与更改包 1204:1 关联。
在这种情况下,MDT 开发人员的所有工作现在都已检入到变型开发路径中,并且将成为 2.0a 版本的一部分。但是,需要将 MDT 错误修复工作传送回主要开发路径,以便将其合并到下一个产品版本中。PT 开发人员需要选取可处理错误修复的更改,并在沙盒中应用它们。“重新同步更改包”是最适合应用新修复的选项。
PT 开发人员会为同一个项创建第二个更改包 1204:2。第二个更改包包含摘要“已将修复应用至主要开发路径”。PT 开发人员会启动“重新同步更改包”命令,选择主要开发沙盒,以及此项中的第一个更改包 - 1204:1。第二个更改包 1204:2 用来作为传播更改包。
解决所有合并冲突后,开发人员会提交传播更改包,并且 Windchill RV&S 会应用来自所参考的更改包中的更改。
现在,主要开发路径和变型开发路径中都处理了错误修复,从而确保问题在 2.0a 版本以及下一主产品版本中得到修复。