BranchManager for DOORS® supporte la création de plusieurs branches d'un projet dans DOORS®, en conservant les relations (liens et modules de liens) entre la structure complète des modules DOORS®. L'identification unique des exigences est maintenue à travers toutes les branches, permettant ainsi de visualiser l'historique à travers les branches sources et leurs enfants, ainsi que la fusion à travers les branches.
La création d'une branche correspond à la copie d'un module DOORS® en conservant des références de ces copies. Les changements réalisés sur une copie peuvent être fusionnés avec une autre branche.
A partir de la version 9.5, il n'y a pas de concept naturel pour créer une branche dans DOORS®.
A noter que la création de branche est faite au niveau d'un module, c'est-à-dire que durant la création de la branche, une copie d'un module formel est créée (à voir aussi Qu'est ce que BranchManager for DOORS® copie?).
Dans la suite de la documentation, on appelle le module d'origine et les modules copiés des 'modules parallèles'.
Afin d'être cohérent avec DOORS®, BranchManager for DOORS® défini une branche comme étant un projet DOORS®. Dans ce projet, il ne peut pas y avoir de modules parallèles, c'est-à-dire que lorsque l'on fait une branche d'un module, la cible doit être dans un autre projet DOORS®. Lorsque l'on fait une comparaison ou une fusion de module, seulement la branche cible (projet) aura besoin d'être sélectionnée. BranchManager for DOORS cherchera le module automatiquement. BranchManager for DOORS® inclus des données dans les modules copiés pendant la création de la branche. Ces données sont conservées sous la forme d'un module spécifique et d'attributs sur les objets qui permettent d'identifier le module à partir duquel la branche a été réalisée et les fusions qui ont été faites pour chaque objet.
Lorsque l'on créé une branche pour un module DOORS®, BranchManager for DOORS® fait une copie de tous les objets et attributs du module (avec quelques exceptions) vers le module cible. Les objets conservent leur hiérarchie (dans le module) et leur identifiant unique. En fonction du cas d'utilisation pour la création de la branche, il peut être intéressant de donner au module cible un préfixe différent (afin d'avoir des identifiants d'objets différents) dans les deux branches. Comme pour les modules, les objets copiés sont appelés ‘objets parallèles’ dans cette documentation.
BranchManager for DOORS® copie aussi les liens sortants du module DOORS® copié. Pour avoir des détails sur le traitement des liens, veuillez consulter le chapitre sur le Traitement des liens. Les liens entrants, en cohérence avec ce que propose DOORS®, ne font pas partie du module source et ne seront pas copiés (voir aussi Création incrémentale d'une branche et Traitement des liens pendant la création d'une branche.
Si seulement le module source est copié, mais qu'il existe déjà un module parallèle dans la branche, et qu'il y a aussi un objet parallèle pour le lien cible,
alors BranchManager for DOORS® va re-copier le lien dans la branche cible.
En utilisant cette stratégie, une hiérarchie de modules peut copier un couple de modules en même temps, pourvu que la création de branche soit réalisée du haut de la hiérarchie vers le bas (voir aussi Création d'une branche incrémentale).
S'il n'y a pas de module parallèle pour la cible du lien dans la branche cible, alors BranchManager for DOORS® recréera le lien si l'option “Recréer les liens version les projets distants” est sélectionnée. Dans ce cas, le lien sera créé vers le même objet cible que le lien d'origine.
Sinon, le lien sera ignoré et un message d'information sera renvoyé à la fin de la création de la branche.
S'il y a un module parallèle pour la cible du lien dans la branche cible, mais que dans ce module l'objet parallèle n'existe pas (par exemple il n'a pas encore été fusionné, ou alors il a été supprimé)
alors BranchManager for DOORS® recréera le lien vers la cible d'origine seulement si l'option “Rediriger les liens des objets qui sont manquants dans la branche cible vers les objets de la branche source” est sélectionnée.
Sinon le lien sera ignoré et un message d'information sera renvoyé à la fin de la création de la branche.
En général, les modules de liens sont valides à l'intérieur du projet, où se situent les liens.
Donc, lorsque BranchManager for DOORS® copie un lien ou un ensemble de liens d'un module DOORS®, il vérifiera si le module de lien correspondant est situé dans le même projet que le module source.
Dans ce cas, BranchManager for DOORS® fera aussi une copie du module de lien. Si un module utilise un module de lien en dehors de son projet, alors ce module de lien sera ré-utilisé,
c'est-à-dire que les liens et les ensembles de liens de la branche cible utiliseront le même module de liens.
Lors de la création d'une branche, BranchManager for DOORS® copiera les restrictions sur les liens du module source. De cette façon, dans le cas nominal, l'utilisateur sera capable d'éditer dans la branche
juste après la copie, sans avoir à changer l'organisation des liens dans la branche. Les modules cibles et les modules de liens sont réactualisés en fonction
de la disponibilité des modules cibles et de liens dans la branche cible.
Cependant, dans certains cas, comme faire une copie de deux modules d'un projet conséquent vers un espace de travail privé, cela pourrait conduire vers le résultat non désiré de liens dans les modules cibles,
qui pointent vers des modules dans le projet source, encore accessible dans la branche cible (Voir aussi Traitement des liens).
Dans ce cas, BranchManager for DOORS® a une option qui "autorise seulement les liens à l'intérieur de la branche cible".
Cette option permettra seulement la création des ensembles de liens pour les modules copiés, qui ont leur module cible dans la branche. Dans le schéma suivant, les liens vers branche source sont encore là, mais ils ne sont pas éditables.
Les branches peuvent être créées de manière incrémentale afin de gérer la taille et le temps de création. Comme décrit dans le chapitre Traitement des liens pendant la création d'une branche, BranchManager for DOORS® créera les liens vers les modules qui existent dans la branche cible. Ceci peut être utilisé pour créer une branche d'un nouveau module à partir d'une branche source vers d'autres branches, par exemple pour mettre à jour une branche de résolution de bugs avec de nouveaux modules. Lorsque la branche entière est réalisée, il n'est pas nécessaire de se préoccuper de l'ordre puisque BranchManager for DOORS® fera en sorte de créer les modules dans le bon ordre.
La création de branche incrémentale commence par le haut de la hiérarchie puis descend vers le bas. Les modules liens cibles font soit partie de l'opération de création de branche, ou existent déjà dans la branche cible.
Lors de la création d'une branche, la branche recopiera la hiérarchie des dossiers, qu'il y ait un ou plusieurs modules à migrer. Si l'utilisateur décide de restructurer la branche, il n'y a pas de limitation et les relations avec la branche source restent les mêmes. Lorsque deux branches ont des structures de dossiers différentes, il faut faire attention lorsque l'on veut créer une branche pour de nouveaux modules à partir d'une branche vers l'autre. BranchManager for DOORS® créera les modules dans leur structure d'origine, ensuite ces modules doivent être bougés manuellement vers l'endroit désiré de la nouvelle branche. A noter que l'historique du module ne prendra pas en compte la modification manuelle, puisque BranchManager for DOORS® ne prend pas en compte les changements sur les dossiers. Cela n'affectera pas les fonctionnalités mais doit être gardé en mémoire afin d'éviter des confusions lorsque l'on retrace l'historique du module. Pour la même raison, il n'est pas recommandé de bouger un module formel vers une branche différente. Bien que cela n'affectera pas les fonctionnalités de l'outil, cela pourrait créer de la confusion lorsque les utilisateurs visualisent l'historique de la branche du module.
Quelques points importants doivent être pris en compte lorsque l'on crée une branche:
L'historique de branches d'un module contient:
La version commune pour le module de la branche C et le module de la branche B est la version de référence 1.1 de la branche A, puisque c'est la dernière
version de référence que les deux modules ont en commun dans leur historique. Après cette version de référence, leur historique diverge, c'est-à-dire qu'entre
la version de référence 1.1 et la version de référence 2.0 de la branche A il y a des changements sur le module de la branche A,
qui n'appraissent pas dans l'historique de la branche B.
Cela montre que la base commune de deux modules n'est pas nécessairement une version de référence de chaque module. Puisque la base commune est importante pour l'intégration de deux modules, il faut garder en tête que:
Bien que la création de branche fait une copie complète du module source, quelques différences entre le module source et sa copie peuvent être observées:
Nom de l'attribut | Périmètre | Description |
BranchManager Internal ID | Module | Cet attribut de module contient une copie de la base de données contenant les modules, ainsi que l'identifiant du module. Il est nécessaire lors de la détection de la copie, au niveau du module. Format: <db-ID>:<mod-ID> où <db-ID> est l'identifiant de la base <mod-ID> est l'identifiant du module |
BranchManager Internal Reference Long | Module + Objet | L'attribut "BranchManager Internal Reference Long" , au niveau module, contient une référence vers la branche racine (i.e. le plus vieil ancêtre - le module qui a été copié en premier
dans l'historique du module) et l'ancêtre immédiat du module (qui est le module à partir duquel la branche a été créée) Format: <db-root>:<mod-root>::<db-ancestor>:<mod-ancestor>où <db-root> est l'identifiant de la base dans la branche racine <mod-root> est l'identifiant du module dans la branche racine <db-ancestor> est l'identifiant de la base de l'ancêtre immédiat <mod-ancestor> est l'identifiant du module de l'ancêtre immédiat L'attribut "BranchManager Internal Reference Long", au niveau objet, contient une référence vers la branche racine de l'objet (i.e. le plus vieil ancêtre - l'objet qui a été copié en premier dans l'historique de l'objet) et une référence vers l'objet lui-même (utilisé pour la détection des copies): Format: <db-root>:<mod-root>:<abs-root>::<db-this>:<mod-this>:<obj-this> où <db-root> est l'identifiant de la base de l'objet racine de la branche <mod-root> est l'identifiant du module de l'objet de la branche racine (leading zeros stripped) <abs-root> est l'Absolute Number de l'objet racine de la branche <db-this> est l'identifiant de la base courante <mod-this> est l'identifiant du module courant (leading zeros stripped) <abs-this> est l'Absolute Number de l'objet courant |
BranchManager Branch History | Module + Objet | L'attribut "BranchManager Branch History" est une entrée qui décrit l'historique de branche pour les objets et modules. Format pour un module: |INTBS|<date>|<reason>|<srcFullName>|<tgtFullName>|<srcID>|<srcBaseline>|<tgtID>|<tgtBaseline> où: <date> est la date (i.e. date/heure de la version de référence) en utilisant le format: yyyy-MM-dd hh:mm:ss <reason> est le type, i.e. "Integration-Baseline", "Branch" ou "Baseline" <src<reason>|<srcID>|<srcBaseline>|<srcObject>|<tgtID>|<date>|FullName> le nom complet de la source de l'intégration, ou la source de la branche ou le nom complet du module au moment de la version de référence <tgtFullName> le nom complet de la cible de l'intégration, ou de la cible du module au moment de la version de référence d'intégration (<n/a> en cas de "version de référence") <srcID> l'ID du module ou de la source de l'intégration, ou de la source de la branche ou du module qui a été versionné <srcBaseline> la version de référence de la source de l'intégration, ou de la source de la branche ou du module qui a été versionné <tgtID> l'ID du module ou de la source de l'intégration, ou de la source de la branche (<n/a> en cas de "version de référence") <tgtBaseline> la version de référence de la source de l'intégration, ou de la source de la branche (en cas de "version de référence") Format pour un objet: |HIST|<reason>|<srcID>|<srcBaseline>|<srcObject>|<tgtID>|<date>| ou: <reason> la raison de l'entrée i.e.. "Branch" ou "Merge" <srcID> L'ID du module source à partir duquel les objets viennent <srcBaseline> La version de référence du module à partir duquel le module vient. <srcObject> L'Absolute Number de l'objet source <tgtID> L'ID du module cible <date> est un entier représentant la date et l'heure |
BranchManager Current Integration | Module | L'attribut est vide s'il n'y a pas eu d'intégration sur le module. S'il y a eu une intégration, l'attribut stocke les paramètres de l'intégration tel que: |INT|<srcID>|<srcBase>|<tgtID>|<tgtBase>| où: <srcID>, <scrBase>, <tgtID>,<tgtBase> sont les identifiants du module source, de la base source, du module cible, de la base cible, dans le format: id[(suffixe major.minor)] où id est l'identifiant du module et [(suffixe major.minor )] est la version de référence (mis de côté en cas de version courante). |
BranchManager Last Integrated On | Objet | Cet attribut est vide au démarrage d'une intégration et stocke la date et l'heure de la dernière opération "Marqué comme intégré" / Fusion. De cette façon, le script de fusion peut reconnaître que l'objet source de l'intégration a changé après que l'objet ait été fustionné (dans le cas où le module source est une version courante). Si c'est le cas, l'objet apparaîtra dans l'interface d'intégration. |
BranchManager Integration/Merge Changes | Objet | Cet attribut est vide au démarrage d'une intégration et enregistre toutes les opérations de fusion. Il peut être utilisé pour filtrer les objets ayant déjà été fusionnés dans l'intégration courante. |
BranchManager Integration Options | Module | Cet attribut stocke les paramètres d'intégration. Format: <deleted>|<structure>|<attributes>|<link>|<attribute 1>|<attribute 2>|...|<attribute n> où: <deleted> vrai ou faux, doit être pris en compte dans le cas d'objet nouveau ou supprimé <structure> vrai ou faux, doit être pris en compte dans le cas d'un changement de hiérarchie <link> vrai ou faux, doit être pris en compte en cas de changement sur un lien <attribute x> le nom des attributs qui doivent être intégrés. |