Résolution de conflits binaires
Lorsqu'un conflit entre deux révisions d'un fichier binaire survient, Windchill RV&S remplace le fichier de travail de sandbox de ce membre par la révision de destination et le marque comme un conflit. La révision de destination s'affiche dans le lot de propagation comme une entrée Deferred Check In (représentant une intégration différée du fichier de travail). Par exemple, si les révisions 1.1 et 1.1.1.1 sont toutes les deux des entrées de révision de mise à jour d'un membre binaire dans un lot de modifications requérant une fusion avec la révision actuelle 1.2, le contenu de la révision 1.1.1.1 est utilisé pour le fichier de travail de sandbox de la révision actuelle 1.2. La révision 1.2 s'affiche comme entrée Deferred Check In dans le lot de propagation. Aucune comparaison du contenu du fichier binaire n'est fournie. Lorsque le lot de modifications est soumis (ou le membre intégré), la révision actuelle est 1.3.
Vous pouvez résoudre le conflit de l'une des manières suivantes :
• Utiliser la révision cible
Soumettez les modifications dans le lot de propagation, intégrant ainsi la révision de destination du membre binaire (ou soumettez manuellement l'intégration différée de la révision de destination).
• Effectuer une fusion binaire manuelle
À l'aide d'un outil tiers extérieur à Windchill RV&S, effectuez une fusion binaire sur le membre affecté. Soumettez ensuite les modifications dans le lot de propagation (ou soumettez manuellement l'intégration différée de la révision de destination).
• Utiliser la révision d'origine
Ignorez l'entrée Deferred Check In correspondant à ce conflit et utilisez ainsi la révision d'origine au lieu de la révision de destination. Pour résoudre le conflit, indiquez la révision souhaitée à l'aide d'une opération Deferred Update Revision.