Resultierende Änderungen werden festgelegt, indem für jedes Mitglied bzw. Unterprojekt, das die resultierende Änderung für dieses Mitglied oder Unterprojekt darstellt, eine einzelne Operation berechnet wird. Damit ist das Zielprojekt äquivalent zum Quellprojekt.

Für den Befehl "Änderungspaket anwenden" muss die resultierende Änderung einem vorhandenen Artefakt im Repository entsprechen. Für ein Mitglied muss z.B. die resultierende Änderung einer vorhandenen Revision im Archiv dieses Mitglieds entsprechen (es sei denn, die resultierende Änderung besteht im Entfernen des Artefakts). Wenn die resultierende Änderung nicht in einem vorhandenen Artefakt gelöst werden kann (möglicherweise aufgrund einer erforderlichen Zusammenführung), schlägt die Propagierung fehl, und müssen Sie als Benutzer stattdessen die Aufgabe mit dem Befehl "Änderungspaket erneut synchronisieren" ausführen.

Der Befehl "Änderungspaket erneut synchronisieren" berechnet auch eine einzelne Operation für jedes Mitglied bzw. Unterprojekt. Im Gegensatz zu "Änderungspaket anwenden" wird "Änderungpaket erneut synchronisieren" jedoch in einer Sandbox ausgeführt und lässt Zusammenführungen in der Sandbox zu. Diese wird eingecheckt, um eine neue Revision im Archiv des Mitglieds zu erstellen, wenn das Propagierungs-Änderungspaket eingereicht wird. Es gibt jedoch Beschränkungen hinsichtlich der Komplexität der Zusammenführung. Wenn das Generieren der einzelnen Operation für ein Mitglied beispielsweise eine Zusammenführung (oder Trennung) von zwei oder mehreren voneinander unabhängigen Revisionssätzen aus dem Archiv des Mitglieds erfordert, schlägt die Operation fehl. Es ist weiterhin möglich, die Änderungen in den meisten Fällen zu propagieren, aber die Propagierung muss in mehrere Teile unterteilt und nacheinander ausgeführt werden.

Für das Verständnis, wie Windchill RV&S resultierende Änderungen bestimmt, ist wichtig, dass Windchill RV&S eine Änderung als bereits von der Quelle zum Ziel propagiert einstuft, wenn die Mitgliedsrevision im Ziel bereits in (oder außerhalb) der Revision ist, die von der resultierenden Änderung als zu propagierend angezeigt wird. Dies wirkt sich insbesondere in zwei Fällen aus: Erstens bei der erneuten Propagierung einer Änderung aus dem Quellprojektbaum in den Zielprojektbaum; zweitens bei der Propagierung einer Änderung, bei der eine Mitgliedsrevision an eine vorherige Stelle im Verlauf verschoben wird. In beiden Fällen legt Windchill RV&S fest, dass das Ziel bereits über die erforderliche Änderung verfügt, und führt daher keine Aktion aus. Dies wird in folgendem Beispiel dargestellt:

Der Entwickler John verfügt über das Mitglied bar.txt für die Revision 1.6 in der Quellprojekthierarchie. Dasselbe Mitglied existiert jedoch auch für die Revision 1.5 in der Zielprojekthierarchie. In der Quellhierarchie erstellt John ein neues Änderungspaket 1:1, das einen Eintrag enthält, der die Operation "Mitgliedsrevision aktualisieren" für bar.txt bis zur Revision 1.4 ausführt. Wenn eine andere Benutzerin, Mary, versucht, dieses Änderungspaket mit "Änderungspaket verwenden" (oder "Änderungspaket erneut synchronisieren") in das Ziel zu propagieren, führt Windchill RV&S keine Operation aus, da die Änderung bereits auf das Ziel angewendet wurde (da Revision 1.5 auf 1.4 basiert). Wenn Mary im Ziel die Rückstellung der Mitgliedsrevision auf 1.4 erzwingen möchte, muss dies manuell ohne die Befehle "Änderungspaket anwenden" (bzw. "Änderungspaket erneut synchronisieren") durchgeführt werden.

Diese Art der Feststellung, welche Änderungen für das Ziel bereits angewendet wurden, basiert auf Revisionsnummerierung. Das Ignorieren dieser Änderungen ist für die Verarbeitung der Befehle wesentlich und wirkt sich ebenfalls auf den Abgleichvorgang aus.

Für das Verständnis, wie Windchill RV&S resultierende Änderungen bestimmt, ist außerdem wichtig, dass nur Änderungen bei der Propagierung berücksichtigt werden, die die Konfiguration der Mitglieder und des Unterprojekts des Projekts betreffen. Beispielsweise ist es möglich, neue Revisionen mithilfe eines Änderungspakets in ein Archiv einzuchecken und zugleich anzugeben, dass diese neuen Revisionen die Mitgliedsrevision im Projekt nicht aktualisieren sollen. Beim Propagieren dieses Änderungspakets in das Ziel werden jene Einträge vom Befehl ignoriert, da sie die Mitgliedskonfiguration im Quellprojekt nicht aktualisieren.

Windchill RV&S verarbeitet die resultierenden Änderungen durch das interne Erstellen eines virtuellen Buckets für alle Mitglieder bzw. Unterprojekte, die auf der Liste von zu propagierenden Änderungspaketen enthalten sind (einschließlich der von Ihnen als Benutzer explizit angegebenen Änderungen und derjenigen, die Sie zum Übernehmen aus der Abgleichsliste angeben). Windchill RV&S untersucht schrittweise alle Änderungspaket-Einträge in diesen Änderungspaketen in der ursprünglichen Reihenfolge und fügt den Eintrag anschließend zum entsprechenden Bucket hinzu. Die Änderungen werden folgendermaßen gruppiert:

Damit Windchill RV&S die Änderungen aus dem Quellprojektbaum in den Zielprojektbaum propagieren kann, muss Windchill RV&S das entsprechende Zielmitglied oder Unterprojekt für jedes Quellmitglied bzw. Unterprojekt suchen (oder gegebenenfalls hinzufügen oder erstellen).

Wenn Windchill RV&S feststellt, dass ein Unterprojekt im Ziel fehlt, wird das entsprechende Varianten-Unterprojekt im Ziel sofort während der anfänglichen Berechnungsphase der zu propagierenden resultierenden Änderungen erstellt (obwohl Sie als Benutzer im Voraus zur Bestätigung dieser notwendigen Operation aufgefordert werden). Auf diese Weise erstellte Varianten-Unterprojekte bleiben in der Zielhierarchie erhalten, auch wenn Sie später die Propagierung abbrechen. Es ist wichtig, dass Sie diese Beschränkung von Windchill RV&S verstehen. Alle anderen Änderungen des Zielprojektbaums werden nur festgeschrieben, falls und wenn Sie die Möglichkeit hatten, den Satz der durchzuführenden resultierenden Änderungen zu untersuchen und Sie die Fortführung der Propagierung bestätigen.