Les versions divergent à mesure que des modifications leur sont apportées dans l'arborescence des versions. Le processus dit de « réconciliation et réinjection » consiste à extraire les modifications apportées à une ancienne version et à les fusionner avec celles de votre version. Lorsque vous avez terminé la mise à jour d’une version, vous pouvez fusionner les modifications apportées dans une autre version. Dans le cas du versionnement traditionnel, vous pouvez combiner ces modifications dans n’importe quelle version ascendante, telle que la version parent ou Default (Par défaut).
Des conflits peuvent survenir si d'autres utilisateurs ont modifié la version ascendante de votre version depuis que vous avez commencé à l'utiliser. Ils sont détectés lorsque vous réconciliez vos mises à jour avec la version cible.
ArcGIS Pro résout les conflits détectés en faveur de la version que vous mettez à jour ou de la représentation de la version cible, selon vos préférences. Une fois les conflits résolus, vous pouvez les examiner un par un et les modifier, si nécessaire. Par exemple, si un conflit est résolu en faveur de la version de mise à jour, vous pouvez choisir de le remplacer en faveur de la version cible ou même d'utiliser les outils de mise à jour pour le modifier d'une autre manière.
Remarque :
Cette rubrique décrit le traitement de réconciliation et de réinjection via l’onglet Versioning (Versionnement). Vous pouvez également réconcilier et réinjecter des versions à l’aide de l’outil de géotraitement Réconcilier des versions et du bouton Reconcile/Post (Réconcilier/Réinjecter)
de l’onglet Versions lorsque vous êtes dans la vue Versions.Processus de réconciliation
Dans le cas du versionnement traditionnel, pour réconcilier vos mises à jour avec une version ascendante, vérifiez que les conditions suivantes sont respectées :
- Vous êtes actuellement le seul utilisateur à mettre à jour la version traditionnelle que vous réconciliez.
- Aucun autre utilisateur ne peut mettre à jour la version cible. Une exception s’applique si la version cible est Default (Par défaut). Vous pouvez procéder à une réconciliation vers la version Default (Par défaut) même lorsque d’autres utilisateurs la mettent à jour.
- Vous devez être en mesure de voir la version cible, ce qui signifie qu'elle doit être publique ou protégée. Si elle est privée, vous devez en être le propriétaire ou être l'administrateur de la géodatabase.
- Si votre processus prévoit qu’un utilisateur effectue la mise à jour et un autre la réconciliation, assurez-vous que ce dernier bénéficie d’autorisations complètes sur l’ensemble des classes d’entités et des tables qui ont été modifiées dans la version. Si ce n’est pas le cas, l’utilisateur ne peut pas procéder à la réconciliation. L'utilisateur qui effectue la réconciliation doit bénéficier d'autorisations complètes sur les deux côtés de la relation modifiée, quelle qu'elle soit, y compris les relations de base ou composites. Dans ce type de workflow, l'utilisateur qui effectue la réconciliation doit également disposer d'autorisations suffisantes sur la version. Il doit pouvoir modifier la version à réconcilier (qui doit donc être publique) et afficher la version cible (qui doit donc lui appartenir ou être publique ou protégée).
Pour modifier la façon dont les conflits sont gérés pendant la réconciliation, reportez-vous à la rubrique Options de version pour la mise à jour.
Pour procéder à la réconciliation, vous pouvez accéder à la commande Reconcile (Réconcilier) sur l’onglet Versioning (Versionnement) en cliquant sur le bouton List By Data Source (Répertorier par source de données) 
dans la fenêtre Contents (Contenu). Pour commencer le traitement de réconciliation, cliquez sur le bouton Reconcile (Réconcilier) sur l’onglet Versioning (Versionnement). La boîte de dialogue Réconcilier apparaît.
Lorsque la boîte de dialogue Réconcilier apparaît, entrez les informations suivantes :
- Précisez la version cible.
- Indiquez comment vous souhaitez définir les conflits. Les options suivantes s'offrent à vous :
Définir les conflits à ce niveau Pour détecter ces cas Ligne (par objet)
Un deuxième utilisateur met à jour la même ligne ou entité, ou les mêmes entités topologiquement liées, que vous. Le conflit survient même si vous avez modifié différents attributs.
Colonne (par attribut)
Un deuxième utilisateur modifie le même attribut d'une entité ou d'une table. Il s’agit de l’option par défaut.
Options de définition d'un conflit - Comment souhaitez-vous résoudre les conflits avec ArcGIS Pro ? Les options suivantes s'offrent à vous :
Résoudre les conflits Description En faveur de la version de mise à jour (que vous modifiez)
Toutes les entités en conflit de la version en cours sont prioritaires sur les représentations en conflit dans la version cible.
En faveur de la version cible
Toutes les entités en conflit de la version en cours sont remplacées par leurs représentations dans la version cible.
Options de résolution d’un conflit
Remarque :
Vous ne pouvez pas utiliser l'opération Annuler pour annuler une réconciliation. Pour annuler une réconciliation, vous pouvez effacer les modifications sans les enregistrer.
Pour réconcilier les mises à jour de votre version traditionnelle avec une version ascendante, procédez comme suit :
- Cliquez sur Reconcile (Réconcilier) dans le groupe Versionnement (Versioning) sous l’onglet Versionnement (Versioning).
La boîte de dialogue Réconcilier apparaît.
- Choisissez la version cible.
- Spécifiez comment vous souhaitez définir les conflits.
- Indiquez si vous souhaitez résoudre tous les conflits en faveur de la version de mise à jour ou de la version cible.
- Cliquez sur OK.
En cas de conflits, ArcGIS Pro les résout selon votre préférence. Une fois les conflits résolus, vous pouvez les réviser un par un et les modifier si nécessaire. Par exemple, si un conflit est résolu en faveur de la version mise à jour, vous pouvez choisir de la remplacer en faveur de la version cible ou utiliser les outils de mise à jour pour la modifier différemment.
La réconciliation actualise uniquement la version de mise à jour pour qu’ArcGIS Pro puisse rechercher les conflits ; elle ne fusionne pas les modifications dans la version cible. Après avoir effectué la réconciliation et examiné les conflits, vous pouvez procéder à la fusion en réinjectant vos modifications dans la version cible.
Examiner les conflits dans la vue Conflicts (Conflits)
Lorsque vous effectuez une réconciliation et que des conflits sont détectés, vous pouvez choisir de les examiner à l’aide de la vue interactive Conflicts (Conflits). Vous pouvez ancrer cette vue n’importe où dans l’application ou l’afficher sous forme de fenêtre flottante. Cela vous permet d’interagir en même temps avec une vue Map (Carte) afin de fournir du contexte et d’explorer davantage les données.
La vue Conflicts (Conflits) contient toutes les classes en conflit, ainsi que leurs entités ou lignes en conflit. Les conflits sont organisés selon leur source de données, leur classe, leur catégorie et leur ObjectID. Les classes de conflits représentent les couches en conflit pour la totalité de la géodatabase.
La vue Conflicts (Conflits) vous permet également d’effectuer les opérations suivantes :
- Déterminer les champs ou lignes en conflit.
- Visualiser les conflits.
- Marquer les conflits comme examinés ou non examinés.
- Résoudre les conflits en désignant la représentation à utiliser pour remplacer des entités ou des attributs.
Des conflits surviennent dans les instances suivantes :
- La même entité est actualisée à la fois dans la version en cours de mise à jour et la version cible.
- La même entité est actualisée dans une version et supprimée dans l’autre.
- Une entité ou une classe de relations reliée topologiquement est modifiée dans la version mise à jour et une version cible.
La vue Conflicts (Conflits) contient également une section Conflict Display (Affichage des conflits) qui permet d’afficher les différentes représentations pour les mises à jour de géométrie. Le contenu de l’affichage des conflits dépend de la présence de la classe en conflit dans la carte active :
- Lorsque la classe en conflit figure dans la carte active, le conflit affiche toutes les couches de carte, utilise la symbologie de la carte et inclut le fond de carte.
- Si la classe en conflit ne figure pas dans la carte active, le conflit affiche uniquement la couche en conflit, utilise la symbologie par défaut et n’inclut pas le fond de carte.
Déterminer les champs ou lignes en conflit
Toutes les classes et entités en conflit sont répertoriées dans la zone de liste affichée dans l’angle supérieur gauche de la vue Conflicts (Conflits). Cette liste vous indique le nombre total de conflits dans toutes les classes d’entités.
Cliquez sur la flèche de liste déroulante d’un objet pour afficher les conflits liés à chaque entité. Ils sont répartis en trois catégories possibles :
- Update-Delete (Mettre à jour-Supprimer) : l’entité a été mise à jour dans la version actuelle et supprimée dans la version cible.
- Delete-Update (Supprimer-Mettre à jour) : l’entité a été supprimée dans la version actuelle et mise à jour dans la version cible.
- Update-Update (Mettre à jour-Mettre à jour) : l’entité a été mise à jour dans les deux versions, actuelle et cible.
Lorsque vous sélectionnez l’ObjectID d’une entité individuelle dans la liste, les colonnes et les attributs des versions actuelle, cible et d’ascendant commun de l’entité apparaissent dans la grille d’informations à droite de la vue Conflicts (Conflits).
Les attributs et valeurs de toutes les représentations d’une entité en conflit vous permettent de visualiser comment les valeurs attributaires diffèrent dans les versions et vous aident à sélectionner la représentation des données à conserver.
- La version actuelle représente les mises à jour que vous avez effectuées au niveau de l’entité et de ses attributs.
- La version cible représente l’entité et ses attributs mis à jour et réconciliés par un autre utilisateur. Il s’agit de la version cible que vous avez sélectionnée à l’ouverture de la vue Conflicts (Conflits).
- La version Ascendant commun représente l'entité et ses attributs tels qu'ils figurent dans la base de données (l'état de l'entité et des attributs avant les modifications).
Un indicateur rouge à gauche de la ligne signale un conflit. Par exemple, si la géométrie de l’entité a été mise à jour dans chaque version, un indicateur rouge apparaît à côté du champ Shape (Forme).
Si d’autres champs attributaires sont en conflit, un indicateur rouge apparaît à gauche de la ligne. Si une entité a été supprimée dans l’une des versions, la mention <Deleted> (<Supprimé>) apparaît comme valeur attributaire de la version.
Si des entités ont été insérées dans la version de mise à jour et qu’elles font partie d’un conflit, la mention <Did not exist> (<N’existait pas>) apparaît dans les versions Target (Cible) et Common Ancestor (Ascendant commun).
Deux boutons au bas de la boîte de dialogue vous permettent de voir tous les champs ou uniquement ceux qui sont en conflit.
Remarque :
Tous les champs sont affichés dans la vue Conflicts (Conflits) ; toutefois, les champs sur lesquels un filtre des conflits est appliqué ne sont pas identifiés comme étant en conflit et n’affichent pas d’indicateur rouge.
Marquer comme examiné ou comme non examiné
Une fois que vous avez déterminé les champs ou lignes en conflit, vous pouvez marquer une entité comme examinée. Vous pouvez effectuer le suivi des entités que vous avez examinées car celles marquées comme examinées n’apparaissent plus en gras dans la liste.
Si vous décidez de revenir ultérieurement sur un conflit d’entité, cliquez avec le bouton droit sur l’ObjectID dans la liste Conflicts (Conflits), puis sélectionnez Mark as not reviewed (Marquer comme non examiné). L'entité s'affiche de nouveau en gras.
Si vous cochez la case Filter Reviewed Conflicts (Filtrer les conflits examinés) en haut de la vue, vous pouvez filtrer la liste pour n’afficher que les conflits qui n’ont pas encore été examinés.
Résoudre les conflits
Lorsque vous résolvez des conflits, vous choisissez la représentation des entités et des attributs que vous souhaitez conserver. Quelle que soit la version en faveur de laquelle vous souhaitez effectuer une réconciliation (version cible ou mise à jour), vous pouvez spécifier la représentation à conserver : actuelle (telle qu’elle apparaissait dans votre version avant la réconciliation), cible (telle qu’elle apparaît dans les modifications apportées par un autre utilisateur) ou d’ascendant commun (telle que l’entité ou l’attribut apparaît dans la version cible).
Il existe quatre options de remplacement permettant de résoudre des conflits :
- Remplacement d'attribut :
Cette méthode est appliquée au niveau du champ. Si les attributs présentent des conflits, vous pouvez simplement remplacer la valeur attributaire dans la version actuelle par l’une des représentations : actuelle, cible ou d’ascendant commun. Pour ce faire, cliquez avec le bouton droit sur l'attribut en conflit, puis sélectionnez l'option de votre choix dans le menu contextuel.
- Remplacement d'entité :
Cette méthode est appliquée au niveau de la ligne. Vous pouvez remplacer une entité complète par la représentation de l’entité dans la version actuelle, cible ou d’ascendant commun. Cela signifie que tous les champs en conflit sont remplacés.
- Remplacement au niveau de la classe :
Vous pouvez choisir de remplacer la représentation actuelle de la classe d’entités complète par la représentation de la version actuelle, cible ou d’ascendant commun afin de résoudre le conflit. Cette méthode remplace l'ensemble des entités et attributs conflictuels en une seule fois, ce qui vous permet d'actualiser et de remplacer rapidement les entités conflictuelles. Si la liste Differences (Différences) contient plusieurs entités, toutes sont remplacées par la version de votre choix.
Pour choisir une option de remplacement au niveau de la classe, cliquez avec le bouton droit sur le nom de la classe d’entités dans la liste Differences (Différences), puis sélectionnez la version que vous souhaitez utiliser.
- Remplacement complet :
Il s'agit d'un remplacement au niveau de la racine L'utilisation de cette option de remplacement remplace toutes les entités et classes d'entités en conflit de la liste par la représentation sélectionnée. Si plusieurs classes d'entités et objets sont en conflit, ils sont tous remplacés par la version de votre choix.
Cliquez avec le bouton droit sur les informations de version et de connexion en haut de la liste Differences (Différences) et sélectionnez la version à utiliser pour remplacer tous les conflits.
Filtrage des conflits au niveau des champs
Dans certains cas d’utilisation du versionnement traditionnel, lorsque des conflits sont détectés lors de la réconciliation, il peut être préférable de conserver des mises à jour appliquées à un champ ou à un ensemble de champs. Voici quelques cas au cours desquels vous souhaiterez peut-être filtrer les conflits détectés dans un champ lors d’une réconciliation :
- Une mise à jour par lots est effectuée sur un champ dans différentes versions
- Des informations sont écrites dans un champ en fonction des mises à jour effectuées au sein de la version
Pour empêcher l’identification des conflits lorsque le même attribut est mis à jour dans les versions parent et enfant, vous pouvez utiliser l’outil Ajouter un filtre des conflits de champs pour définir l’ensemble des champs dans lesquels les conflits doivent être filtrés. Un filtre des conflits de champs permet de baliser un champ ou un ensemble de champs au sein des classes d’entités pour les éliminer de la détection des conflits. Les conflits ne sont pas renvoyés pendant la réconciliation si vous ne mettez à jour que des champs sur lesquels des filtres de conflits sont activés. Cette option n'est disponible que lorsque vous définissez des conflits par attribut.
Remarque :
Tous les champs sont affichés dans la vue Conflicts (Conflits) ; toutefois les champs sur lesquels un filtre des conflits est appliqué ne sont pas identifiés comme étant en conflit et n’affichent pas d’indicateur rouge.
Lorsque la réconciliation est terminée, la valeur placée dans le champ présentant un filtre des conflits varie selon que vous avez choisi d'effectuer une réconciliation en faveur de la version cible ou de la version de mise à jour. Si vous avez choisi d'effectuer la réconciliation en faveur de la cible, les champs avec un filtre des conflits affiche la valeur de la version cible. Si vous avez choisi d'effectuer la réconciliation en faveur de la mise à jour, les champs avec un filtre des conflits affiche la valeur de la version de mise à jour.
L'outil Supprimer le filtre des conflits de champs peut supprimer ces filtres de conflits de ces champs. La fonction Python ListFieldConflictFilters permet de savoir si des filtres de conflits ont été définis pour une table ou une classe d'entités.
Remarque :
Lorsqu’un filtre des conflits de champs est défini pour une table ou une classe d’entités, les clients ArcGIS antérieurs à la version 10.2.1 ne peuvent pas ouvrir la table ou la classe d’entités. Les filtres des conflits de champs peuvent être définis dans un champ, puis supprimés après la réconciliation des versions, si les versions antérieures de ArcGIS ont besoin d’accéder aux données.
Résoudre les conflits avec des règles attributaires
Les règles attributaires améliorent l’expérience de mise à jour et renforcent l’intégrité des données des jeux de données des géodatabases. La réconciliation d’une classe d’entités versionnée de manière traditionnelle avec un calcul immédiat ou des règles de contrainte évalue ces règles attributaires. Si une règle de contrainte est enfreinte, l’erreur associée est signalée et la réconciliation échoue. Réconciliez les conflits par ligne afin d’éviter toute erreur de règle de contrainte.
Résoudre des conflits avec des classes de relations
Il est possible d’utiliser des classes de relations pour renforcer l’intégrité référentielle entre des objets reliés. Si des sources de données versionnées participent à une classe de relations, le processus de rapprochement évalue l’intégrité référentielle de ces données. Si elle n’est pas respectée, les entités impliquées sont signalées comme des conflits et peuvent être examinées dans la vue Conflicts (Conflits).
La suppression d’une entité d’une classe de relations source risque de générer un message entraînant la suppression d’une entité de la classe de relations destinataire. Soyez conscients des ramifications lorsque vous décidez d'effectuer un remplacement lors de conflit impliquant des classes d'entités qui font partie de classes de relations.
Voici un exemple de conflit susceptible de survenir entre des classes de relations :
- Dans une version parent, vous ajoutez une entité de destination et la relier à une entité dans la classe d’origine.
- Dans une version enfant, vous supprimez la même entité d’origine qui a été utilisée pour établir la relation avec la nouvelle entité de destination.
- Lorsque les mises à jour sont réconciliées, un conflit supprimer-mettre à jour est détecté sur la classes d’origine.
Voici un autre exemple :
- Dans votre jeu de classes d'entités d'installations électriques, vous supprimez un pylône relié à un transformateur, ce qui entraîne la suppression de celui-ci.
- Dans une autre session de mise à jour simultanée, un éditeur modifie les attributs du transformateur que vous venez de supprimer en supprimant son pylône associé.
- Lorsque les mises à jour sont réconciliées, un conflit mettre à jour-supprimer est détecté sur les classes d’origine et de destination.
Dans ce dernier exemple, si le second éditeur choisit de remplacer tous les conflits par les représentations de la session de modification, le pylône et le transformateur supprimés lors de votre session de modification sont recréés.
Réinjecter les modifications
Pour réinjecter des modifications dans la version cible, vous devez avoir accès en mise à jour sur cette version. Cela signifie que la propriété d’accès de la version doit être définie sur Public ou que vous devez être l’administrateur des versions.
Pour réinjecter des modifications dans la version cible après avoir réconcilié et examiné les conflits, cliquez sur Post (Réinjecter) dans le groupe Versioning (Versionnement) sur l’onglet Versioning (Versionnement).
Astuce :
Les autres utilisateurs qui lisent la version cible dans laquelle vous avez réinjecté les modifications ne les voient qu'après avoir actualisé leurs espaces de travail versionnés.
Informations supplémentaires sur la réinjection :
- Vous pouvez uniquement réinjecter des modifications si la version cible est restée intacte depuis votre dernière réconciliation des modifications. Si la version cible a été modifiée entre temps, vous devez recommencer la réconciliation avant la réinjection.
- Vous ne pouvez plus annuler les modifications qui ont été réinjectées, car vous apportez des modifications à une version que vous n'êtes pas en train de mettre à jour.
- Après la réinjection, vous pouvez continuer à modifier votre version. Pour appliquer ces modifications dans la version cible, vous devez à nouveau procéder à la réconciliation, à la résolution des conflits et à la réinjection.
Si la réinjection signale la fin de votre votre processus, vous pouvez, si vous le souhaitez, supprimer la version que vous avez mise à jour.
Vous avez un commentaire à formuler concernant cette rubrique ?