净更改通过计算每个成员或子项目的单一操作（该操作表示该成员或子项目的净更改）来确定，以使目标项目等于源项目。

对于“应用更改包”命令，净更改需要对应于存储库中的现有构件。例如，对于成员，净更改需要对应于该成员存档中的现有修订版本（除非净更改是删除该构件）。如果无法将净更改解析为现有构件（可能是因为需要合并），则传播将会失败，而且您（用户）必须改用“重新同步更改包”命令来执行任务。

“重新同步更改包”命令也会计算每个成员或子项目的单一操作，但与“应用更改包”不同的是，“重新同步更改包”会在沙盒啥下文中操作，并且允许在沙盒中进行合并，这些合并将被检入，从而在提交传播更改包时，在成员存档中创建新的修订版本。但是，合并在复杂度上存在限制。例如，如果为成员生成单一操作需要并入（或并出）成员存档中两个或多个不连续的修订版本集，则该操作将会失败。大多数情况下仍可以传播更改，但需要将传播分解为更小的部分并按顺序执行。

如果目标中的成员修订版本已经达到（或高于）净更改指明应该传播的修订版本，则在了解 Windchill RV&S 如何确定净更改时要注意的一个重要因素是，Windchill RV&S 会将更改视为已经从源传播到目标。具体来说，这在两种情况下存在影响：第一，当您尝试将更改重新从源项目树传播到目标项目树时；第二，当您尝试传播沿其历史记录向后移动成员修订版本的更改时。在这两种情况下，Windchill RV&S 都会判定目标中已存在所需的更改，因此不会执行任何操作。示例如下：

开发员 John 在源项目层次结构中具有修订版本 1.6 的成员 bar.txt，但在目标项目层次结构中，同一成员为修订版本 1.5。在源层次结构中，John 按原样创建了一个新更改包，其中的条目会对 bar.txt 执行“更新成员更改包”操作以将其还原为修订版本 1.4。如果另一个用户 Mary 尝试使用“应用更改包”（或“重新同步更改包”）将此更改包传播到目标，则 Windchill RV&S 不会执行任何操作，因为目标已具有此更改（顾名思义，修订版本 1.5 是以 1.4 为基础构建的）。如果 Mary 想将目标中的成员修订版本强制还原为 1.4，则必须手动执行此操作，并且无法依靠“应用更改包”（或“重新同步更改包”）来完成。

这种确定目标“已经有”哪些更改的行为基于修订版本编号。忽略这些更改是命令流程的基础，并且也会影响回填流程。

了解 Windchill RV&S 如何确定需要了解的净更改时需要注意的另一个重要因素是，传播时只会考虑对项目成员和子项目配置产生实际影响的更改。例如，可使用更改包将新修订版本检入存档，此时会指明这些修订版本不应该更新项目中的成员修订版本。将此更改包传播到目标时，命令会忽略那些条目，因为它们不会更新源项目中的成员配置。

Windchill RV&S 会通过下列方式处理净更改：在内部为它在要传播的更改包列表（包括您 (用户) 明确指定的更改以及您指定在回填中选择的更改）中遇到的每个成员或子项目创建一个虚拟存储段。Windchill RV&S 会按照原始出现顺序逐一检查那些更改包中的所有更改包条目，然后将条目添加至适当的存储段中。更改按照下列方式分组：

Windchill RV&S 必须找出每个源成员或子项目对应的目标成员或子项目（或在必要时添加或创建），Windchill RV&S 才能将更改从源项目树传播到目标项目树。

对于子项目，如果 Windchill RV&S 确定目标中缺少某个子项目，则会在计算要传播的净更改的初始阶段，立即在目标中创建对应的变型子项目（但是系统会提前提示您 (用户) 要这样做，并询问是否确定要继续）。通过这种方式创建的变型子项目会保留在目标层次结构中，即使您稍后决定取消传播；您需要了解，这是 Windchill RV&S 的限制。只有在您有机会检查要执行的净更改集，并且同意继续传播时，才会执行对目标项目树所做的所有其他更改。