Configuration d'un sous-projet de gestion de configurations

Une fois que vous avez créé ou ajouté un sous-projet, vous pouvez en modifier le type afin de répondre à vos besoins. Par exemple, vous pouvez transformer un sous-projet normal en un sous-projet figé pour suspendre le développement ou vous pouvez transformer un sous-projet variant en un sous-projet normal pour continuer le développement sur le tronc principal.

Par exemple, Jen souhaite que l'équipe de développement des outils ABC travaille avec la révision 1.2 de amortissement/projet.pj, la dernière version stable connue du code. Jen ne veut pas que l'équipe de développement général effectue un développement supplémentaire dans cette version, de ce fait, elle configure le sous-projet amortissement/projet.pj en sous-projet figé.

Interface	Procédure
Interface utilisateur graphique	Sélectionnez Configurer le sous-projet.
Interface Web	Sélectionnez Projet > Configurer le sous-projet.

Lors de la configuration d'un sous-projet, vous pouvez spécifier l'un des types suivants :

• L'option Variante n'est pas disponible si aucun chemin de développement n'est disponible.

• Les chemins de développement désactivés ne s'affichent pas dans la liste Nom du chemin de développement.

• Build configure un sous-projet statique en fonction d'un point de contrôle spécifique du projet utilisé pour construire ou tester le projet, mais pas pour un développement ultérieur. Vous pouvez spécifier le point de contrôle par son numéro de point de contrôle ou son étiquette.

Toute modification apportée lors de la configuration d'un sous-projet a une incidence sur tout le projet ainsi que sur tous les sous-projets partagés qu'il contient. Les deltas reflétant ces modifications apparaissent dans la vue Projet ou Sandbox. Voici quelques différences que vous pouvez voir :

• les membres qui existent dans la version d'origine et dans la version configurée du sous-projet affichent un delta si la révision de travail dans la sandbox est différente de la nouvelle révision actuelle ;

• les membres qui n'existaient pas dans la version d'origine du sous-projet mais qui existent dans le sous-projet configuré affichent un delta pour indiquer que la sandbox ne dispose pas de fichier de travail pour le nouveau membre ;

• les membres qui existaient dans la version d'origine du sous-projet mais qui n'existent pas dans le sous-projet configuré s'affichent en tant qu'anciens membres ;

• les sous-projets qui existaient en tant que membres dans la version d'origine du sous-projet mais qui n'existent pas dans le sous-projet configuré apparaissent en tant qu'anciens sous-projets.

Pour résoudre les différences, resynchronisez la sandbox subordonnée.

Lorsque vous configurez des sous-projets partagés, n'oubliez pas que chaque sous-projet partagé est configuré de façon indépendante. De ce fait, lorsque vous configurez un sous-projet partagé, la reconfiguration ne modifie pas toutes les instances de ce sous-projet. Par exemple, si le sous-projet tools/project.pj est partagé dans les deux projets Aurora/project.pj et Libra/project.pj, une modification apportée à la configuration de Aurora/tools/project.pj n'affecte pas la configuration de Libra/tools/project.pj.

Les sous-projets configurés ou figés créés dans Source Windchill RV&S Standard (une version antérieure de Windchill RV&S) sont détectés lorsque Windchill RV&S y accède, sans perturber l'opération. Le format de ces sous-projets est conservé jusqu'à ce que vous le modifiiez ou le mettiez à jour vers le nouveau format en le reconfigurant.