Réconcilier des versions
Dans ce module, vous allez exécuter l’outil Reconcile/Post (Réconcilier/Réinjecter) pour réconcilier simultanément les deux versions nommées (Imperial Work Order 1 (Bon de travail pour Imperial 1) et Imperial Work Order 2 (Bon de travail pour Imperial 2)) avec la version par défaut.
Accéder aux données en tant qu’administrateur de versions
Dans ce didacticiel, vous endosserez le rôle d’administrateur de versions. Les administrateurs de versions disposent d’un accès illimité pour consulter, mettre à jour et gérer les versions de branche, indépendamment du propriétaire de la version ou de l’autorisation d’accès. Dans le versionnement de branche, les utilisateurs de portail suivants peuvent agir en tant qu’administrateurs de versions :
- Le propriétaire de la couche d’entités Web (généralement l’utilisateur qui a publié le service d’entités)
- Un utilisateur du portail qui s’est vu attribuer le rôle Administration
- Un utilisateur du portail qui se voit attribuer un rôle personnalisé disposant du privilège Manage all (Gérer tout)
Vous correspondez à la première définition car vous avez publié les données de Madrid dans le premier didacticiel de cette série : Préparer et publier des données en branche versionnées. Vous allez vous connecter à votre portail avec les informations d’identification qui ont servi lors du partage des données.
- Démarrez ArcGIS Pro.
- Sous New Project (Nouveau projet), cliquez sur Start without a template (Démarrer sans modèle).
- Au-dessus du ruban, cliquez sur Not signed in (Non connecté) et sur Sign in (Se connecter).
- Dans la fenêtre ArcGIS Sign In (Connexion à ArcGIS), saisissez le nom d’utilisateur et le mot de passe du compte de portail que vous avez utilisé dans le premier didacticiel de cette série : Préparer et publier des données en branche versionnées.
- Dans la fenêtre Catalog (Catalogue), cliquez sur l’onglet Portal (Portail), puis sur le bouton My Organization (Mon organisation).
Tous les éléments du portail de votre organisation sont affichés, notamment les éléments Madrid Solar Project (Projet solaire à Madrid) que vous avez créés dans le premier didacticiel.
- Cliquez avec le bouton droit sur la couche d’entités Madrid Solar Project (Projet solaire à Madrid) (l’icône jaune), pointez sur Add To New (Ajouter à une nouvelle), puis cliquez sur Map (Carte).
Les données apparaissent sur une nouvelle carte.
- Dans la fenêtre Contents (Contenu), cliquez sur la flèche en regard de Madrid Solar Project (Projet solaire à Madrid) pour développer le groupe de couches.
Le groupe de couches contient deux couches : Buildings (Bâtiments) et Neighborhoods (Voisinages).
Réconcilier et réinjecter les versions nommées
Dans le didacticiel précédent, Créer des mises à jour dans une version de branche, deux versions nommées ont été créées : Imperial Work Order 1 (Bon de travail pour Imperial 1) et Imperial Work Order 2 (Bon de travail pour Imperial 2). Vous allez ensuite tenter de réconcilier et de réinjecter les deux versions.
La réconciliation consiste à extraire les modifications apportées à la version par défaut et à les fusionner dans la version nommée actuellement connectée. Le processus de réconciliation détecte les conflits entre les deux versions nommées et la version par défaut. La réinjection consiste à envoyer les modifications dans la version par défaut.
- Dans la fenêtre Contents (Contenu), cliquez sur le bouton List By Data Source (Répertorier par source de données).
- Dans la fenêtre Contents (Contenu), cliquez sur la source de données Madrid Solar Project (Projet solaire à Madrid), par exemple sde.DEFAULT (Madrid_Solar_Project).
- Sur le ruban, cliquez sur l’onglet Versioning (Versionnement).
- Dans le groupe Versioning (Versionnement), cliquez sur Manage Versions (Gérer les versions).
La vue Versions apparaît, répertoriant la version par défaut et les deux versions nommées créées dans le didacticiel précédent.
Vous pourriez réconcilier et réinjecter chaque version nommée individuellement, mais vous allez plutôt utiliser l’outil Reconcile/Post (Réconcilier/Réinjecter) pour les traiter toutes les deux en même temps.
- Dans le groupe Manage Versions (Gérer les versions), cliquez sur Reconcile/Post (Réconcilier/Réinjecter).
- Dans la fenêtre Reconcile/Post (Réconcilier/Réinjecter), vérifiez que le paramètre Target version (Version cible) est configuré sur la version par défaut.
Dans le versionnement de branche, la version cible est toujours la version par défaut.
- Dans la zone Edit versions (Versions de mise à jour), cochez les cases de Imperial Work Order 1 (Bon de travail pour Imperial 1) et de Imperial Work Order 2 (Bon de travail pour Imperial 2).
Les versions de mise à jour sont les versions nommées à réconcilier.
- Cochez la case Abort if conflicts detected (Annuler la réconciliation si des conflits sont détectés) et décochez la case Proceed if unreviewed conflicts are detected (Continuer si des conflits non examinés sont détectés).
Avec ces options, le processus de réconciliation est annulé si des conflits sont détectés. Vous pouvez ainsi procéder à l’assurance qualité en examinant et en résolvant manuellement les conflits.
Remarque :
Si vous ne souhaitez pas examiner les conflits, cochez la case Proceed if unreviewed conflicts are detected (Continuer si des conflits non examinés sont détectés). Si vous choisissez cette option, les conflits existants des sessions précédentes sont perdus lors de l’exécution de l’outil. Pour en savoir plus, consultez la documentation Réconcilier des versions.
- Pour How do you want to define conflicts (Mode de définition des conflits), vérifiez que le paramètre By attribute (by column) (Par attribut [par colonne]) est sélectionné.
Ainsi, un conflit est détecté uniquement si des modifications sont apportées au même attribut de la même entité. Si vous choisissez By object (by row) (Par objet [par ligne]), un conflit est détecté pour toute modification apportée à la même entité, par exemple si les mises à jour s’appliquent à différents attributs de la même entité.
- Cochez les cases Post Versions after reconcile (Réinjecter les versions après réconciliation) et Delete versions after post (Supprimer les versions après la réinjection).
Avec ces options, l’outil réinjecte et supprime également la version nommée si aucun conflit n’est détecté lors du processus de réconciliation.
- Cliquez sur OK.
Une fois le processus de réconciliation terminé, un message d’avertissement apparaît.
La première partie du message explique que la version Imperial Work Order 1 (Bon de travail pour Imperial 1) a bien été réconciliée avec la version par défaut, réinjectée dans la version par défaut, puis supprimée.
La deuxième partie du message explique que des conflits ont été détectés lors du processus de réconciliation pour la version Imperial Work Order 2 (Bon de travail pour Imperial 2). C’est pour cette raison que la réconciliation a été annulée et que les mises à jour de cette version n’ont pas été réinjectées dans la version par défaut. Vous devez vous connecter à cette version et résoudre les conflits manuellement.
- Cliquez sur Close (Fermer).
La version Imperial Work Order 1 (Bon de travail pour Imperial 1) est retirée de la vue Versions car elle a été supprimée au cours du processus de réconciliation et de réinjection.
- Fermez la vue Versions.
- Dans la fenêtre Contents (Contenu), vérifiez que l’espace de travail Madrid Solar Project (Projet solaire à Madrid) est connecté à la version DEFAULT (PAR DÉFAUT), par exemple, sde.DEFAULT (Madrid_Solar_Project).
Sur la carte, les bâtiments du quartier Imperial sont symbolisés en orange et rouge. Cela s’explique parce que les mises à jour de la version Imperial Work Order 1 (Bon de travail pour Imperial 1) ont été réinjectées dans la version par défaut.
Dans ce module, vous vous êtes connecté à un compte de portail capable d’agir en tant qu’administrateur de versions. Vous avez utilisé l’outil Reconcile/Post (Réconcilier/Réinjecter) pour réconcilier plusieurs versions nommées dans une seule session. Aucun conflit n’ayant été détecté avec la première version nommée, elle a été réinjectée dans la version par défaut et supprimée. Des conflits ayant été détectés dans l’autre version nommée, le processus de réconciliation a été annulé.
Examiner et résoudre les conflits
Dans ce module, vous allez réexécuter le processus de réconciliation, cette fois uniquement pour la version Imperial Work Order 2 (Bon de travail pour Imperial 2). Le processus de réconciliation détectera un conflit. Vous allez utiliser la vue des conflits pour examiner et résoudre manuellement le conflit.
Examiner un conflit
Commencez par vous connecter à la version Imperial Work Order 2 (Bon de travail pour Imperial 2).
- Dans la fenêtre Contents (Contenu), cliquez avec le bouton droit de la souris sur l’espace de travail Madrid Solar Project (Projet solaire à Madrid), puis sélectionnez Change Version (Changer de version).
- Dans la fenêtre Change Version (Changer de version), cliquez sur la version Imperial Work Order 2 (Bon de travail pour Imperial 2) (par exemple ADMIN.Imperial Work Order 2).
- Cliquez sur OK.
La carte s’actualise sur la version nommée : tous les bâtiments du quartier Imperial sont en jaune pâle, hormis le centre sportif municipal qui est en orange clair.
- Dans le ruban, sur l’onglet Versioning (Versionnement), cliquez sur Reconcile (Réconcilier).
La dernière fois, vous avez utilisé l’outil Reconcile/Post (Réconcilier/Réinjecter) parce qu’il vous permettait de traiter plusieurs versions nommées simultanément. Cette fois, vous allez utiliser l’outil Reconcile (Réconcilier) car il vous permettra d’examiner manuellement les conflits lors de leur détection.
- Dans la fenêtre Reconcile (Réconcilier), vérifiez que le paramètre Define conflicts (Définir les conflits) est défini sur By attribute (column) (Par attribut [colonne]).
Ce processus de réconciliation fusionne les modifications de la version par défaut dans la version Imperial Work Order 2 (Bon de travail pour Imperial 2) et vous avertit lorsque des conflits sont détectés. Un conflit est détecté si un bâtiment a été mis à jour dans les deux versions ou si un bâtiment a été supprimé dans une version, mais pas dans l’autre. Vous aurez l’opportunité d’examiner et de résoudre les conflits.
- Cliquez sur OK.
Une autre fenêtre apparaît, indiquant que des conflits ont été détectés et résolus en faveur de la version de mise à jour. Il s’agit du comportement par défaut du versionnement de branche. La version de mise à jour est la version actuelle : Imperial Work Order 1 (Bon de travail pour Imperial 1).
- Pour Do you wish to review the conflicts (Souhaitez-vous examiner les conflits), cliquez sur Yes (Oui).
La fenêtre Conflicts (Conflits) s’affiche. Elle répertorie les classes d’entités en conflit. Dans ce cas, la classe d’entités Buildings (Bâtiments) est indiquée. Le (1) après son nom indique qu’elle comporte un conflit.
Remarque :
Avec le versionnement de branche, vous pouvez examiner et résoudre les conflits dans plusieurs sessions de ArcGIS Pro. Si vous avez plusieurs conflits, il n’est pas nécessaire de les examiner et de les résoudre tous en même temps.
- Cliquez sur la flèche en regard de la classe d’entités Buildings (Bâtiments) pour la développer et afficher le conflit.
Le type de conflit, Update-Update (Mettre à jour-Mettre à jour), apparaît. Ce type de conflit signifie que l’entité a été mise à jour dans les deux versions, actuelle et cible.
- Développez Update-Update (Mettre à jour-Mettre à jour).
L’ID d’objet de l’entité en conflit (1752) est indiqué.
- Cliquez sur 1752.
La grille d’informations affiche les valeurs attributaires de toutes les représentations de l’entité.
Les trois représentations sont les suivantes :
- Current (Actuelle) : version Imperial Work Order 2 (Bon de travail pour Imperial 2).
- Target (Cible) : version par défaut, qui inclut désormais les mises à jour apportées à la version Imperial Work Order 2 (Bon de travail pour Imperial 2).
- Common Ancestor (Ascendant commun) : état des données d’origine lorsque les versions nommées ont été générées.
Dans la grille d’informations, vous voyez que les versions Target (Cible) et Current (Actuelle) contiennent toutes les deux des modifications apportées au champ POT_SOLAR.
- Au bas de la vue Conflicts (Conflits), cliquez sur la flèche en regard de Conflict Display (Affichage des conflits) pour développer cette section.
La visionneuse Conflict Display (Affichage des conflits) apparaît, présentant l’entité en conflit (1752), sélectionnée sur deux cartes. Vous voyez que l’entité 1752 correspond au bâtiment du centre sportif municipal.
La carte de gauche montre la version Current (Actuelle) (Imperial Work Order 2 (Bon de travail pour Imperial 2)), tandis que la carte de droite montre la version Target (Cible) (par défaut).
Dans la version Current (Actuelle), tous les bâtiments à l’exception du centre sportif municipal ont adopté les valeurs et les couleurs de la version Target (Cible) au cours du processus de réconciliation. Aucun conflit n’a été détecté en ce qui les concerne parce qu’ils ont seulement été mis à jour dans l’une des versions créées à partir de l’ascendant commun, et non dans les deux. La seule différence entre les deux cartes est la couleur du centre sportif municipal, qui est en conflit parce qu’il a été mis à jour dans les deux versions.
Vous avez apporté les mises à jour à l’origine de ce conflit dans le didacticiel précédent, Créer des mises à jour dans une version de branche. Dans la version Imperial Work Order 1 (Bon de travail pour Imperial 1), vous avez réalisé une mise à jour par lot pour calculer le champ Potencialidad solar (Potentiel solaire) (POT_SOLAR). Cette mise à jour a entraîné la valeur relativement élevée de 3,65420923 pour le centre sportif municipal, ce qui explique sa symbolisation en rouge dans la carte Target (Cible). (La symbologie de la couche est déterminée par le champ Potencialidad solar (Potentiel solaire).) Dans la version Imperial Work Order 2 (Bon de travail pour Imperial 2), vous avez appliqué une mise à jour manuelle au bâtiment du centre sportif municipal : vous avez changé la valeur Potencialidad solar (Potentiel solaire) en 1,876058, ce qui explique pourquoi il est symbolisé en orange clair dans la carte Current (Actuelle). Ces valeurs attributaires mises à jour sont également visibles dans la grille d’informations.
Résoudre un conflit
Vous devez ensuite décider quelle représentation du centre sportif municipal accepter. Dans ce scénario, vous allez conserver les mises à jour apportées à la version Imperial Work Order 2 (Bon de travail pour Imperial 2) parce que ces valeurs ont résulté du deuxième cycle d’une enquête de terrain. Cette version représente le rapport le plus récent que vous ayez sur ce bâtiment.
- Dans la vue Conflicts (Conflits), cliquez avec le bouton droit sur 1752 et sélectionnez Add Review Note (Ajouter une remarque sur la révision).
- Dans la fenêtre Add Review Note (Ajouter une remarque sur la révision), saisissez The correct solar potential value is 1.876058 from the latest survey.
La remarque sur la révision est conservée entre différentes sessions d’examen des conflits pour fournir le contexte nécessaire à la résolution des conflits. Les remarques sont particulièrement utiles dans les organisations qui ont plusieurs administrateurs.
- Cliquez sur OK.
- Cliquez avec le bouton droit à nouveau sur 1752 et sélectionnez Mark As Reviewed (Marquer comme révisé).
La mise en forme du texte dans la liste Conflicts (Conflits) passe de Gras à Normal.
Les conflits qui n’ont pas encore été examinés sont affichés en gras, ce qui vous permet d’identifier ceux qui ont fait l’objet d’un examen et les autres.
Remarque :
Dans le versionnement de branche, les conflits sont résolus en faveur de la version actuelle (de mise à jour) par défaut. Dans ce cas, vous avez examiné le conflit et déterminé que la valeur dans la version actuelle est correcte ; aucun autre changement n’est donc nécessaire. Cependant, si vous aviez déterminé que la valeur dans la version cible (par défaut) était correcte, vous pourriez cliquer avec le bouton droit à nouveau sur l’entité et choisir Replace with Target Version (Remplacer par la version cible).
Pour en savoir plus sur la vue Conflicts (Conflits), consultez la documentation Gérer les conflits de versions de branche.
- Sur le ruban, dans l'onglet Edit (Mise à jour), dans le groupe Manage Edits (Gérer les mises à jour), cliquez sur Save (Enregistrer).
- Dans la fenêtre Save Edits (Enregistrer les mises à jour), cliquez sur Yes (Oui).
- Fermez la vue Conflicts (Conflits).
La carte présente tous les bâtiments du quartier Imperial dans des tons rouge et orange. Le bâtiment du centre sportif municipal est en orange clair.
Dans ce module, vous avez utilisé la vue Conflicts (Conflits) pour examiner la représentation actuelle des entités et attributs en fonction de l’opération de réconciliation. Vous avez examiné un conflit et l’avez résolu en conservant les mises à jour apportées à la version actuelle (Imperial Work Order 2 [Bon de travail pour Imperial 2]).
Réinjecter et supprimer une version
Dans ce module, vous allez réaliser l’étape finale du processus d’assurance qualité : vous allez réinjecter les mises à jour validées de la version Imperial Work Order 2 (Bon de travail pour Imperial 2) dans la version par défaut, ce qui les rend accessibles à l’ensemble de l’organisation. Une fois la version réinjectée, vous allez la supprimer.
Réinjecter une version nommée
Vous allez à nouveau réconcilier la version nommée, puis la réinjecter dans la version par défaut.
- Dans la fenêtre Contents (Contenu), vérifiez que l’espace de travail Madrid Solar Project (Projet solaire à Madrid) est connecté à la version Imperial Work Order 2 (Bon de travail pour Imperial 2). Cliquez sur l’espace de travail.
- Sur le ruban, cliquez sur l’onglet Versioning (Versionnement). Dans le groupe Versioning (Versionnement), cliquez sur Reconcile (Réconcilier).
Cette étape peut sembler redondante puisque vous avez déjà réconcilié la version. Il est toutefois important de répéter la réconciliation avant de procéder à la réinjection parce que d’autres éditeurs peuvent avoir réinjecté leurs propres modifications dans la version par défaut pendant que vous vous occupiez de l’assurance qualité. Si ces nouvelles mises à jour sont différentes des vôtres, l’opération de réconciliation détecte de nouveaux conflits.
- Dans la fenêtre Reconcile (Réconcilier), vérifiez que le paramètre Define conflicts (Définir les conflits) est défini sur By attribute (Par attribut). Cliquez sur OK.
La fenêtre Reconcile (Réconcilier) se ferme. Cela signifie qu’aucun nouveau conflit n’a été détecté. Vous pouvez procéder à la réinjection des mises à jour dans la version par défaut.
- Sur l’onglet Versioning (Versionnement), dans le groupe Versioning (Versionnement), cliquez sur Post (Réinjecter).
L’opération de réinjection fusionne vos mises à jour depuis la version Imperial Work Order 2 (Bon de travail pour Imperial 2) dans la version par défaut. Vous allez vous connecter à la version par défaut pour vérifier que les mises à jour ont été fusionnées.
- Dans la fenêtre Contents (Contenu), cliquez avec le bouton droit de la souris sur l’espace de travail Madrid Solar Project (Projet solaire à Madrid), puis sélectionnez Change To Default (Passer à la version par défaut).
La carte s’actualise sans modifier son apparence parce que la version par défaut est désormais identique à la version Imperial Work Order 2 (Bon de travail pour Imperial 2) que vous consultiez auparavant.
- Effectuez un zoom sur le quartier Imperial et cliquez sur le centre sportif municipal.
Dans la fenêtre contextuelle, vérifiez que la valeur Potencialidad solar (Potentiel solaire) est 1.876058 (1,876058).
- Fermez la fenêtre contextuelle.
Supprimer les versions nommées
Votre dernière étape en tant qu’administrateur de versions procédant à l’assurance qualité consiste à supprimer les versions devenues inutiles.
- Dans le ruban, sur l’onglet Versioning (Versionnement), dans le groupe Versioning (Versionnement), cliquez sur Manage Versions (Gérer les versions).
- Dans la vue Versions, cliquez sur la version Imperial Work Order 2 (Bon de travail pour Imperial 2) pour la sélectionner.
La version Imperial Work Order 1 (Bon de travail pour Imperial 1) a déjà été supprimée dans le cadre de l’opération Reconcile/Post (Réconcilier/Réinjecter).
- Sur le ruban, sur l’onglet Versions, dans le groupe Manage Versions (Gérer les versions), cliquez sur Delete (Supprimer).
Dans la vue Versions, la version nommée semble rayée.
- Sur le ruban, dans le groupe Manage Versions (Gérer les versions), cliquez sur Save (Enregistrer).
La version nommée n’apparaît plus dans la vue Versions. Seule la version par défaut demeure.
- Fermez ArcGIS Pro. Il n’est pas nécessaire d’enregistrer le projet.
Dans ce module, vous avez réalisé le processus d’assurance qualité en réinjectant des mises à jour valides dans la version par défaut. Vous avez nettoyé la liste des versions en supprimant la version nommée Imperial Work Order 2 (Bon de travail pour Imperial 2).
Dans ce didacticiel, vous avez agi en tant qu’administrateur de versions pour la couche d’entités Madrid Solar Project (Projet solaire à Madrid). Vous avez réconcilié les deux versions nommées, puis examiné et résolu un conflit détecté dans l’une d’entre elles. Lorsque vous avez estimé que les mises à jour étaient valides, vous les avez réinjectées dans la version par défaut et avez supprimé les versions nommées.
Dans cette série de didacticiels, vous avez suivi un processus de versionnement de branche complet : vous avez activé le versionnement de branche sur une classe d’entités et l’avez publiée dans votre portail en tant que couche d’entités Web. Vous avez créé deux versions nommées, vous vous êtes connecté à chacune d’entre elles et vous avez réalisé des mises à jour dans chacune d’entre elles. Vous avez réconcilié et réinjecté les versions nommées. Les mises à jour se trouvent désormais dans la version par défaut et sont accessibles au reste de votre organisation. Vous êtes maintenant prêt à présenter le processus de versionnement de branche à vos collègues. Vous allez attribuer le rôle d’éditeur à plusieurs personnes et leur montrer comment réaliser et mettre à jour des versions nommées.
À partir de maintenant, ce projet peut évoluer plus rapidement car plusieurs personnes sont capables d’apporter des mises à jour en même temps sans risquer de verrouiller ou de dupliquer les données. Vous connaîtrez le potentiel solaire de chaque bâtiment de Madrid beaucoup plus tôt que si vous n’aviez pas fait appel au versionnement.