Les versions divergent à mesure que des mises à jour leur sont apportées. Après la création d’une version nommée, toutes les mises à jour font l’objet d’un suivi dans la version par défaut et la version nommée. Les mises à jour dans la version par défaut peuvent inclure des mises à jour réinjectées par d’autres versions nommées.
Une fois que vous avez fini de mettre à jour une version nommée, vous pouvez effectuer le rapprochement et la réinjection pour fusionner les mises à jour. Le processus de réconciliation consiste à extraire les modifications apportées à la version par défaut et à les fusionner avec celles de votre version. Vous pouvez ensuite envoyer les modifications que vous avez apportées à la version par défaut via la réinjection.
Des conflits sont détectés lorsque la version nommée est rapprochée de la version par défaut. Lorsque des conflits sont détectés pendant l’opération de rapprochement, ils sont résolus initialement en faveur de la version modifiée. Une invite vous demande si vous souhaitez consulter les conflits à l’aide de la vue Conflicts (Conflits). Vous pouvez les consulter un par un et y apporter des modifications, si nécessaire. Par exemple, vous pouvez utiliser la vue Conflicts (Conflits) pour remplacer un conflit par la version cible ou les outils de modification pour modifier l’entité en conflit d’une autre façon.
Remarque :
Cette rubrique décrit les processus de rapprochement et de réinjection à l’aide de l’onglet Versioning (Versionnement). Vous pouvez également rapprocher et réinjecter des versions à l’aide de l’outil de géotraitement Reconcile Versions (Rapprocher des versions) ou du bouton Reconcile/Post (Rapprocher/Réinjecter)
de l’onglet Versions lorsque vous êtes dans la vue Versions.Processus de réconciliation
Lorsque vous utilisez une version de branche, la réconciliation détecte les conflits entre la version nommée à laquelle vous êtes actuellement connecté et la version par défaut. Si vous tentez de rapprocher des versions et qu’il y a des conflits non marqués comme examinés, le système renvoie un avertissement. Dans le cas du versionnement de branche, vous ne pouvez procéder qu’à la réconciliation avec la version par défaut. Il n’est pas possible d’effectuer une réconciliation avec une autre version nommé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.
Si vous souhaitez procéder à la réconciliation, vous devez utiliser des couches d’entités Web pour lesquelles la fonctionnalité Version Management (Gestion des versions) est activée. 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) dans 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 :
- 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
Remarque :
Les conflits sont toujours résolus en faveur de la version de mise à jour.
Il n’est pas possible d’utiliser des opérations d’annulation pour annuler des modifications apportées après une opération de rapprochement terminée pour des données de branche versionnée.
Dans le cas du versionnement de branche, les conflits sont conservés dans une table GDB_CONFLICTS appartenant au système. Cela vous permet de gérer les conflits sur plusieurs sessions de mise à jour, d’examiner et de résoudre les conflits, de vous interrompre et de continuer ultérieurement. Une seconde opération de rapprochement nettoie la table des conflits et la remplit de nouveau avec les nouveaux conflits qui se sont produits depuis le dernier rapprochement. Cela signifie que vous pouvez perdre l’historique des résolutions de conflits si une seconde réconciliation est effectuée.
En cas de conflits, vous pouvez les examiner dans la vue Conflicts (Conflits).
Le processus de rapprochement n’actualise que la version de modification afin que 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)
Si des conflits sont détectés lors du processus de rapprochement, vous pouvez les examiner dans la vue 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 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 d’entités Web en conflit pour tout le service.
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 cas suivants :
- La même entité est actualisée à la fois dans la version de mise à jour en cours 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 de mise à jour en cours 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 le coin supérieur gauche de la vue Conflicts (Conflits). Cette liste affiche le nombre total de conflits pour les couches d’entités Web pour tout le service.
Cliquez sur la flèche de liste déroulante d’un objet pour afficher les conflits liés à chaque entité. Ils sont répartis selon les catégories suivantes :
- 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 champ et les attributs des versions actuelle, cible et d’ascendant commun de l’entité s’affichent 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 à déterminer la représentation des données à conserver.
- Current (Actuelle) - Représente l’état actuel des entités et des attributs dans la version nommée. Cela inclut toute modification que vous avez apportée.
- Target (Cible) - Représente les entités et les attributs de la version cible.
- Common ancestor (Ascendant commun) - Représente les entités et les attributs lors de la création initiale de la version ou de la dernière opération de rapprochement.
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> apparaît comme valeur attributaire de la version.
Deux boutons dans la partie inférieure de la boîte de dialogue vous permettent d’alterner entre l’affichage de tous les champs ou l’affichage des champs en conflit uniquement.
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) dans la partie supérieure de la vue, vous pouvez filtrer la liste pour n’afficher que les conflits qui n’ont pas été examinés.
Dans le cas du versionnement de branche, vous pouvez également ajouter une remarque sur la révision. Cliquez avec le bouton droit sur une entité, sélectionnez Add Review Note (Ajouter une remarque sur la révision) et saisissez le texte dans la zone de texte Add Review Note (Ajouter une remarque sur la révision). Vous pouvez mettre à jour une remarque sur la révision existante en cliquant avec le bouton droit sur une entité et en sélectionnant Edit Review Note (Mettre à jour la remarque sur la révision).
Remarque :
Les notes d’examen sont effacées lors de l’opération de rapprochement et de réinjection suivante.
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. Après l’opération de rapprochement, vous pouvez utiliser la vue Conflicts (Conflits) pour indiquer la représentation à conserver. Gardez en tête que l’utilisation des options de remplacement dans la vue Conflicts (Conflits) revient au même qu’une opération de modification.
Dans la liste Differences (Différences), cliquez avec le bouton droit sur la version, le jeu de données, l’entité ou l’attribut et sélectionnez l’une des options de remplacement suivantes :
- Replace With Current Version (Remplacer par la version actuelle)
- Replace With Target Version (Remplacer par la version cible)
- Replace With Common Ancestor Version (Remplacer par la version d’ascendant commun)
Voici les différents niveaux auxquels les options de remplacement permettent 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 uniquement 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 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 les champs en conflit sont remplacés.
- Remplacement au niveau de la classe
Vous pouvez 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
Cette méthode est appliquée au niveau de la racine. Cette option remplace toutes les entités et classes d’entités en conflit de la liste par la représentation désigné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, lorsque des conflits sont détectés pendant le rapprochement, il peut être préférable de conserver les modifications d’un champ ou à d’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 dans 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.
Les données de branche versionnée sont toujours rapprochées avec les conflits en faveur de la version de modification. Les champs sur lesquels un filtre des conflits est appliqué contiennent la valeur de la version de modification.
Vous pouvez utiliser l’outil Supprimer le filtre des conflits de champs pour retirer ces filtres des conflits des champs.
Remarque :
Vous devez redémarrer les services comportant des données de branche versionnée pour valider les modifications de l’outil Add Field Conflict Filter (Ajouter un filtre des conflits de champs) ou Remove Field Conflict Filter (Supprimer le filtre des conflits de 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.
Résoudre les conflits avec des règles attributaires
Les règles attributaires améliorent l’expérience de modification et renforcent l’intégrité des données des jeux de données des géodatabases. Lors d’un rapprochement dans lequel des conflits sont définis par attribut (colonne), des règles de calcul ou de contrainte immédiates sont évaluées pour les entités mises à jour dans la version par défaut et la version en cours de rapprochement. Si une règle de contrainte n’est pas respectée pendant ce processus, la fusion n’a pas lieu, l’entité est promue à un conflit Mise à jour-Mise à jour et peut être examinée dans la vue Conflicts (Conflits).
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 de branche versionnée 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 mettre à jour-mettre à jour est détecté sur la classe de destination et un conflit supprimer-mettre à jour est détecté sur la classe 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 par défaut, l’utilisateur du portail en cours doit avoir accès en mise à jour sur cette version. Cela signifie que la propriété d’accès de la version par défaut doit être définie sur Public ou que l’utilisateur du portail soit l’administrateur des versions.
En savoir plus sur l’accès aux versions
Pour réinjecter des modifications dans la version par défaut après avoir réconcilié et examiné les conflits, cliquez sur Post (Réinjecter) dans le groupe Versioning (Versionnement) sur l’onglet Versioning (Versionnement).
Pendant le processus de réinjection, des conflits peuvent être détectés. Cela peut se produire lorsque des modifications sont apportées à la version par défaut après le rapprochement et avant la réinjection. Ces modifications peuvent provenir de modifications directes dans la version par défaut ou de modifications réinjectées à partir d’autres versions nommées. Si cela se produit, une erreur est renvoyée, et vous devez renouveler l’opération de rapprochement avant la réinjection.
Informations supplémentaires sur la réinjection :
- Une fois les modifications réinjectées, vous ne pouvez pas les annuler, car vous apportez des modifications à la version cible.
- Si des conflits n’ont pas été explicitement marqués comme examinés, une boîte de dialogue s’ouvre lorsque vous procédez à une réinjection et vous avertit que les conflits non examinés seront automatiquement résolus. Cliquez sur Yes (Oui) pour résoudre automatiquement les conflits avec l’option que vous avez sélectionnée dans la boîte de dialogue Reconcile (Réconcilier) et réinjecter les modifications dans la version cible.
- 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 ?