Les modifications nettes sont déterminées par le calcul d'une opération unique pour chaque membre ou sous-projet. Cette opération représente la modification nette de ce membre ou sous-projet et vise à rendre le projet cible identique au projet source.

Pour la commande Appliquer le lot de modifications, la modification nette doit correspondre à un objet existant dans le référentiel. Par exemple, dans le cas d'un membre, elle doit correspondre à une révision existante dans l'archive de ce membre (à moins qu'elle ne concerne un déplacement de cet objet). S'il est impossible de résoudre la modification nette dans un objet existant (parce qu'une fusion est requise, par exemple), la propagation échoue et vous (l'utilisateur) devez utiliser la commande Resynchroniser le lot de modifications pour exécuter la tâche.

La commande Resynchroniser le lot de modifications effectue également le calcul d'une opération unique pour chaque membre ou sous-projet. Mais contrairement à la commande Appliquer le lot de modifications, elle fonctionne dans le contexte d'une sandbox et permet d'effectuer les fusions dans la sandbox, qui sera intégrée pour créer une nouvelle révision dans l'archive du membre lorsque le lot de propagation est soumis. Toutefois, le niveau de complexité de la fusion présente certaines limites. Par exemple, si générer l'opération unique pour un membre requiert la fusion (ou l'extraction et la fusion) de plusieurs jeux discontinus de révisions depuis l'archive du membre, l'opération échoue. Dans la plupart des cas, il est toujours possible de propager les modifications, mais la propagation doit être décomposée en plus petites parties et exécutée en séquence.

Un facteur important pour comprendre comment Windchill RV&S détermine les modifications nettes est qu'Windchill RV&S suppose qu'une modification a déjà été propagée de la source vers la cible si la révision actuelle de la cible est déjà à (ou au-delà de) la révision vers laquelle la modification nette doit être propagée. Ceci peut avoir des conséquences spécifiques dans deux cas : premièrement, lorsque vous tentez de propager à nouveau une modification à partir de l'arborescence du projet source vers celle du projet cible ; deuxièmement, lorsque vous tentez de propager une modification qui rétrograde une révision actuelle dans son historique. Dans les deux cas, Windchill RV&S détermine que la cible comporte déjà la modification nécessaire et n'effectue aucune action. Voici un exemple :

John, un développeur, a le membre bar.txt à la révision 1.6 dans la hiérarchie du projet source, mais à la révision 1.5 dans la celle du projet cible. Dans la hiérarchie source, John crée un nouveau lot de modifications 1:1, qui contient une entrée exécutant une opération Mettre à jour la révision actuelle sur bar.txt à la révision 1.4. Si un autre utilisateur, Marie, tente de propager ce lot de modifications vers la cible à l'aide de la commande Appliquer le lot de modifications (ou Resynchroniser le lot de modifications), Windchill RV&S n'effectue aucune opération car la cible comporte déjà la modification (la révision 1.5 est générée implicitement par-dessus la révision 1.4). Si Mary souhaite que la révision actuelle de la cible soit à la révision 1.4, elle doit configurer l'action manuellement et ne peut pas compter sur la commande Appliquer le lot de modifications (ou Resynchroniser le lot de modifications) pour le faire pour elle.

Ce comportement de définition des modifications déjà "contenues" dans la cible repose sur la numérotation des révisions. Ignorer les modifications est une opération fondamentale pour le processus de commande et a également un impact sur le processus de comblement.

Un autre facteur important permettant de comprendre la manière dont Windchill RV&S détermine les modifications nettes est que seules les modifications affectant réellement la configuration de membres et de sous-projet du projet sont prises en compte lors de la propagation. Par exemple, il est possible d'intégrer les nouvelles révisions d'une archive à l'aide d'un lot de modifications et d'indiquer alors que ces nouvelles révisions ne doivent pas mettre à jour la révision actuelle dans le projet. Lors de la propagation de ce lot de modifications vers la cible, ces entrées sont ignorées par la commande car elles ne mettent pas à jour la configuration de membre dans le projet source.

Windchill RV&S traite les modifications nettes en créant en interne un compartiment virtuel pour chaque membre ou sous-projet qu'il rencontre dans la liste des lots de modifications à propager (y compris les modifications explicitement spécifiées par vous (l'utilisateur) et celles à sélectionner dans le comblement). Windchill RV&S étudie l'ensemble des entrées de lot de modifications de ces lots. Il les étudie une par une dans l'ordre dans lequel elles se sont produites puis les ajoute au compartiment approprié. Les modifications sont regroupées de la manière suivante :

Pour qu'Windchill RV&S puisse propager les modifications à partir de l'arborescence du projet source vers celle du projet cible, Windchill RV&S doit localiser (ou ajouter ou créer si nécessaire) le membre ou sous-projet cible correspondant de chaque membre ou sous-projet cible.

Pour les sous-projets, si Windchill RV&S détermine qu'un sous-projet est manquant dans la cible, le sous-projet variant correspondant sera immédiatement créé dans la cible lors de la phase initiale de calcul des modifications nettes à propager (même si vous, (l'utilisateur) recevez un message à l'avance vous indiquant qu'il doit être créé et vous demandant si vous souhaiter continuer). Les sous-projets variants créés de cette manière restent dans la hiérarchie cible, même si vous décidez par la suite d'annuler la propagation. Il s'agit d'une limite d'Windchill RV&S que vous devez comprendre. Les autres modifications apportées à l'arborescence du projet cible ne sont validées que si et lorsque vous avez pu examiner l'ensemble des modifications nettes à exécuter et que vous acceptez de poursuivre la propagation.