Skip To Content

Réconcilier et réinjecter les modifications apportées à une version

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 de branche, vous procédez toujours à la réconciliation et à la réinjection par rapport à la version par défaut. 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 modifications 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.

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 ascendante. 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 ascendante.

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 Reconcile Versions (Réconcilier une version) et le bouton Reconcile/Post (Réconcilier/Réinjecter) Réconcilier et réinjecter dans l’onglet Versions lorsque vous êtes dans la vue Versions.

Processus de réconciliation - Versions traditionnelles

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. Toutefois, s'il s'agit de la version par défaut, vous pouvez effectuer la réconciliation, même si d'autres utilisateurs la modifie.
  • 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 workflow 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 pourra 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 commencer le processus de réconciliation, cliquez sur Reconcile (Réconcilier) dans le groupe Versioning (Versionnement) sur l’onglet Versioning (Versionnement).

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 en choisissant parmi les options suivantes :

    Définir les conflits à ce niveauPour 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

  • Indiquez comment vous souhaitez qu'ArcGIS Pro résolve initialement les conflits : en faveur de la version que vous mettez à jour (c'est-à-dire la version de mise à jour) ou de la version cible. Si la résolution a lieu en faveur de la version cible, toutes les entités conflictuelles de la session de mise à jour actuelle sont remplacées par leurs représentations dans la version cible. Si plusieurs utilisateurs mettent à jour la même version et que des conflits se produisent, l'entité qui a été enregistrée la première remplace la représentation de la session de mise à jour. Si vous choisissez de résoudre les conflits en faveur de la version mise à jour, toutes les entités conflictuelles dans la session de mise à jour actuelle sont prioritaires sur leur représentation dans la version cible.
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 :

  1. Cliquez sur Reconcile (Réconcilier) dans le groupe Versionnement (Versioning) sous l’onglet Versionnement (Versioning).

    La boîte de dialogue Réconcilier apparaît.

  2. Choisissez la version cible.
  3. Spécifiez comment vous souhaitez définir les conflits.
  4. Indiquez si vous souhaitez résoudre tous les conflits en faveur de la version de mise à jour ou de la version cible.

    Si vous choisissez de résoudre les conflits en faveur de la version cible, toutes les entités conflictuelles dans la session de mise à jour actuelle sont remplacées par leur représentation dans la version cible. Si plusieurs utilisateurs mettent à jour la même version et que des conflits se produisent, l'entité qui a été enregistrée la première remplace la représentation de la session de mise à jour. Si vous choisissez de résoudre les conflits en faveur de la version de mise à jour, toutes les entités conflictuelles de la session de mise à jour actuelle sont prioritaires sur leurs représentations dans la version cible.

  5. Cliquez sur OK.

Processus de réconciliation - Versionnement de branche

Lorsque vous utilisez une version de branche, la réconciliation avec la version par défaut détecte les modifications entre cette dernière et la version nommée à laquelle vous êtes actuellement connecté. 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 gérer des versions de branche, accédez à une couche d’entités web à partir de votre connexion au portail ArcGIS Enterprise. La fonctionnalité Version Management (Gestion des versions) du service d’entités sous-jacent de la couche d’entités web doit être activée. La propriété de la version et son accès dépendent de l’utilisateur du portail.

  • L’utilisateur du portail connecté peut afficher les versions de branche qu’il possède, ainsi que toutes les versions publiques et protégées.
  • L’utilisateur du portail connecté peut gérer les versions de branche qu’il ou elle possède.
  • Les utilisateurs du portail suivants peuvent afficher et gérer toutes les versions de branche de la couche d’entités web :
    • Propriétaire de la couche d’entités
    • Administrateur du portail

    Remarque :
    Lorsque vous accédez à la vue Versions à partir d’une connexion à une base de données, l’administrateur de la géodatabase peut afficher et modifier les propriétés des versions, ainsi que supprimer des versions de branche. Les versions de branche de tous les services qui accèdent aux jeux de données dans la géodatabase sont répertoriées dans la vue Versions.

Lorsque vous accédez à des sources de données de branche versionnée en tant que couches d’entités Web, les outils Reconcile (Réconcilier) et Post (Réinjecter) sont disponibles. Pour commencer le traitement de réconciliation, cliquez sur le bouton Reconcile (Réconcilier) dans l’onglet Versioning (Versionnement). La boîte de dialogue Reconcile (Réconcilier) apparaît. La réconciliation des versions de jeux de données faisant partie d’une branche versionnée s’effectue dans les conditions suivantes :

  • Les conflits sont résolus en faveur de la version de mise à jour.
  • Les conflits sont définis par objet au niveau de la ligne.

Il n’est pas possible d’utiliser les options Undo (Annuler) ou Discard (Annuler) pour annuler les modifications apportées après une opération de réconciliation terminée pour des données de branche versionnée.

Vous pouvez afficher les éventuels conflits dans la vue Conflicts (Conflits).

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 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. Elle vous permet également d'effectuer les opérations suivantes :

  • Déterminer les champs ou lignes en conflit
  • Afficher 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.

En cas de conflits dans une version traditionnelle, ArcGIS Pro les résout en faveur de la représentation de la version de mise à jour ou de la version cible, selon votre préférence. Dans une version de branche, les conflits sont toujours résolus en faveur de la version de mise à jour. 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.

Dans le cas du versionnement de branche, les conflits sont conservés dans une table possédée par le système nommée GDB_CONFLICTS. 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 réconciliation nettoie la table des conflits et la renseigne à nouveau avec les nouveaux conflits qui se sont produits depuis la dernière réconciliation. Cela signifie que vous pouvez perdre l’historique des résolutions de conflits si une seconde réconciliation est effectuée.

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 sur 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 enfant 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.

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.

Grâce au versionnement de branche, vous pouvez aussi ajouter une remarque sur la révision en cliquant avec le bouton droit sur une entité, en sélectionnant Add Review Note (Ajouter une remarque sur la révision) et en saisissant 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).

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 différentes 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 seront 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 d’éviter l’application des mises à jour à 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.

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. Cette option n'est disponible que lorsque vous définissez des conflits par attribut. 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 Ajouter un filtre des conflits de champs peut servir à définir l'ensemble des champs dans lesquels les conflits doivent être filtrés. 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éinjecter les modifications

Après avoir effectué la réconciliation et examiné tous les conflits, vous pouvez réinjecter les modifications dans une version ascendante.

  1. Cliquez sur Post (Réinjecter) dans le groupe Versioning (Versionnement) sur l’onglet Versioning (Versionnement) .
Astuce :

Dans le versionnement traditionnel, 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.

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 devrez 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.

Dans le cas du versionnement de branche, 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, quelle que soit 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 projet ou de votre workflow, vous pouvez supprimer la version que vous avez mise à jour. Vous pouvez supprimer une version à condition d'en être le propriétaire et d'avoir préalablement supprimé toutes ses versions enfant.