Quand le contrôle de version avec ArcSDE les modifications publiées peuvent-elles être annulées ou rejetées?

J'utilise ArcGIS 9.3.1 et j'essaie de travailler avec une géodatabase SDE (avec une classe d'entités surfaciques) qui a déjà été enregistrée comme versionnée. Je suis nouveau dans le versioning et j'essaie toujours de comprendre certaines de ses fonctions de base. Jusqu'à présent, je n'ai pas été en mesure de découvrir s'il est possible "d'annuler" ou de "rejeter" certaines modifications une fois qu'elles ont été publiées dans une version parent.

Par exemple, supposons que nous ayons trois versions: le SDE.DEFAULT d'origine qui a été créé lors de son enregistrement comme versionné, une version enfant de la valeur par défaut appelée SDE.QA (pour l'assurance qualité) et une version enfant du QA appelée SDE .Edit1 (où les modifications ont d'abord lieu). Si certaines fonctionnalités de SDE.Edit1 ont été modifiées (par exemple, pour rester simple, disons qu'un polygone a été ajouté et qu'un a été supprimé), puis SDE.Edit1 a été réconcilié avec SDE.QA puis posté sur SDE.QA, y aurait-il serait-il possible d'annuler ce changement plus tard? Dans le prolongement de cette question, serait-il possible de rejeter uniquement certains changements? Par exemple, accepter d'ajouter le premier poly, mais refuser de supprimer le deuxième poly?

Autant que je sache, une fois que les modifications ont été publiées dans la version parent, toutes ces modifications font désormais partie "permanente" (faute d'un meilleur mot) de la version parent. Je suis conscient du fait que ces changements sont tous enregistrés dans deux tables, les tables "ADD" et "DELETE" (souvent appelées tables "delta"), et ne changent pas réellement le FC d'origine lui-même. J'ai envisagé de modifier manuellement ces tables delta, mais j'ai trouvé suffisamment de personnes en garde contre cela pour savoir que ce n'était probablement pas la bonne solution.

C'est peut-être ma compréhension du versioning qui nécessite un certain travail, mais je n'arrivais pas à trouver un moyen de rejeter ou d'annuler une modification une fois qu'elle a été publiée. Cela me semble étrange, car cela signifierait qu'il n'y a aucun moyen d'annuler un message contenant une erreur. Je n'arrive pas non plus à trouver un moyen de retracer la lignée de ces versions (c'est-à-dire quelle version est l'enfant de quel parent). Pendant que je suis sur le sujet, si quelqu'un pouvait connaître des références ArcSDE particulièrement utiles (liens, articles, livres, etc.) qui pourraient m'aider à comprendre ArcSDE (et peut-être répondre à certaines de ces questions), ce serait très apprécié. !

Bien que les réponses aient jusqu'à présent été utiles (merci pour les liens), je ne trouve toujours pas de réponse au cœur de ma question. Encore une fois, c'est peut-être ma propre incompréhension de la situation. Voici ce que je veux savoir:

Pouvez-vous inverser (par inverse, je veux dire annuler ) une publication une fois qu'elle a été créée d'une version enfant vers une version parent? Dans ce scénario, le parent peut être, mais ne doit pas être, la version SDE.DEFAULT. Encore mieux, j'aimerais savoir si vous pouvez inverser une partie d'un post (par exemple, une seule modification dans un polygone), après qu'il a été publié? Je voudrais également savoir si cela peut se faire sans qu'il soit nécessaire de détecter des conflits.

Le fait que je ne trouve pas de réponse claire à cette question (c'est-à-dire «oui» ou «non») documentée quelque part me fait penser que je manque quelque chose d'important au sujet de la gestion des versions dans ArcSDE. Je préférerais également éviter de manipuler les tables A et D manuellement.

Pouah. La réponse est vraiment compliquée et nécessite beaucoup de connaissances d'ArcSDE, je vais donc essayer d'être aussi bref que possible.

Remarque Je vais me référer à certains diagrammes du livre blanc de version super génial que vous pouvez trouver sur le site ESRI . Si vous avez affaire au contrôle de version, je vous encourage vivement à le lire attentivement.

Ensuite, vous devez comprendre quelle est la relation entre un état (c'est-à-dire un nœud de l'arbre d'état) et une version nommée (c'est-à-dire une étiquette pointant vers un état).

Une base de données typique peut ressembler au diagramme d'état ci-dessous:

Ici, vous avez quatre versions dans la base de données (Version A, Version B, Version C et DEFAULT). Mais peut-être que j'ai un peu d'avance sur moi. Commençons par ce qu'est un état .

Vous pouvez considérer un état comme une "transaction" - une unité logique qui contient plusieurs modifications sur une ou plusieurs tables. Il peut inclure deux insertions à "FeatureClass A", une suppression de "Feature Class B" et une modification (en fait une suppression + un insert) à "Feature Class X". Tous regroupés en un seul.

Regardons un petit diagramme d'état ArcSDE simple qui commence à l'ID d'état 0:

Si vous commencez à l'état 0 et que vous effectuez des modifications sur une ou plusieurs tables dans une opération de modification, vous allez créer un état enfant 1 et en faire celui d' ID d'état actif actuel . Un autre groupe de modifications ultérieures créera l'état enfant 2. Si vous souhaitez annuler, vous n'avez pas besoin de modifier l'ID d'état en aucune façon - tout ce que vous devez faire est de changer l'ID d'état actif actuel à 1 ou 0 (selon jusqu'où vous voulez aller). Un rétablissement est l'inverse - déplacez simplement l'ID de l'état actif actuel vers l'avant - aussi loin que vous le souhaitez.

C'est ainsi que l'annulation / la restauration fonctionne dans la version d'ArcSDE.

OK, continuons. Supposons que vous souhaitiez rendre une modification permanente (c'est-à-dire que vous souhaitez enregistrer). Que dois-tu faire? Eh bien, enregistrer, c'est simplement saisir une étiquette de version et la déplacer vers un état particulier. Un peu comme l’estampiller et dire "voici à quoi doit ressembler la version A". Donc, si vous regardez en arrière le premier diagramme, vous verrez qu'il a quatre versions nommées .

• La version B pointe vers l'état id 1
• La version A pointe vers l'état id 3
• La version C pointe vers l'état id 5

• La version "SDE.DEFAULT" pointe vers l'ID d'état 4

  Veuillez noter que ce diagramme, malgré la croyance populaire, ne vous dit rien sur la relation logique parent-enfant qu'ils ont. La relation parent-enfant logique pour le premier diagramme pourrait effectivement ressembler à ceci:

Il s'agit de la relation parent-enfant que vous voyez dans ArcMap / ArcCatalog. Son but est de restreindre les versions avec lesquelles vous pouvez vous réconcilier. À ce stade, vous pourriez (à juste titre) vous demander, pourquoi diable ai-je besoin de cela? La réponse réside dans les workflows de gestion des versions . Il s'avère que les gens utilisent le versionnage depuis un certain temps et il existe des façons préférées de les structurer, mais c'est un sujet pour un autre jour car je veux répondre à votre question aujourd'hui :)

Continuons ...

OK, alors que font les autres versions nommées? Eh bien, ils affectent le comportement de ce processus appelé compress .

La compression consiste à récupérer des états intermédiaires qui peuvent ne pas être nécessaires, à supprimer ceux qui sont inutiles et à les combiner. Vous pouvez déclencher l'opération de compression ArcSDE via ArcCatalog, configurer un service qui le fait tout le temps et certaines opérations de modification ArcMap déclencheront des opérations de mini-compression (c'est-à-dire uniquement pour les petites branches utilisées).

Le diagramme de gauche montre un arbre d'état avant qu'il ne soit compressé, et celui de droite le montre juste après sa compression:

Un concept important à comprendre (auquel je ferai référence une fois que j'aurai enfin répondu à votre question) est que chaque état est un candidat potentiel à compresser - à l'exception des États qui ont des étiquettes (c'est-à-dire des versions nommées) pointées vers eux.

Vous pouvez voir qu'avant la compression, il y a des états supplémentaires inutiles. En fait, toute la branche [3,4,5] a été supprimée. S'il y avait eu une version nommée à 5, le résultat final aurait été très différent.

Les opérations de compression sont là pour économiser de l'espace sur votre base de données en supprimant les enregistrements dont vous n'avez plus besoin.

OK, continuons.

Le dernier concept que vous devez comprendre est la réconciliation - qui consiste à fusionner efficacement deux branches en une seule.

Revenons donc à notre tout premier diagramme. Supposons que vous souhaitez réconcilier la version A avec SDE.DEFAULT.

Récapitulons: quatre versions nommées pointant vers différents identifiants d'état. Donc, la première chose que nous devons faire, c'est créer un état enfant sous la version cible, donc nous créons un état enfant sous l'état id 4, dans notre exemple, j'appelle cet état id 20.

L'étape suivante consiste à calculer les différences entre les deux versions (les détails sont trop longs pour ce post, mais je peux vous dire qu'elles sont effectuées avec des curseurs de différence ), puis à appliquer ces différences à ce nouvel identifiant d'état 20 (ligne bleue).

Supposons que vous décidiez d'effectuer plus de modifications ou que vous ayez trouvé des conflits et que vous choisissiez des lignes dans une version ou dans l'autre. Ça n'a pas d'importance. Ce ne sont que de nouvelles modifications, et sont effectuées dans une opération de modification, comme les états enfants sous la branche que vous avez fusionnée. Dans cet exemple, j'ai effectué deux autres groupes consécutifs de modifications après la réconciliation.

Charmant.

Alors maintenant, dites que vous êtes prêt à " poster " la version. Qu'est-ce que ça veut dire? C'est juste saisir les étiquettes et les pointer vers le même identifiant d'état. Ici, je vais publier la version A sur SDE.DEFAULT. Voici à quoi ça ressemble:

TADAAA! Alors maintenant, la version A et SDE.DEFAULT pointent vers le même identifiant d'état, et donc ils se ressemblent.

OK, maintenant je peux enfin répondre à votre question.

Pouvez-vous annuler un message? La documentation ArcGIS vous dira non - ne vous en faites pas. Ne le faites pas, car vous allez jouer avec cette logique, et si vous ne savez pas ce que vous faites, vous pouvez corrompre vos données.

Mais en vérité, il suffit de faire une mise à jour de l'une des tables de version d'ArcSDE - la table VERSIONS, et de modifier l'entrée de l'étiquette (alias version nommée). Dans notre exemple, pointez sur l'état id 21, et vous venez d'annuler toute l'opération d'édition. Réglez-le sur 3 et vous venez d'annuler la réconciliation entière. Réglez-le sur 5 et vous êtes maintenant dans un endroit complètement différent. Qu'il y ait ou non des conflits est sans importance.

Bien sûr, cela suppose qu'aucune compression ne s'est produite. Prenons le cas où la compression se produit exactement au même moment où vous mettez à jour la table SDE. N'oubliez pas que si vous - ou quelqu'un d'autre - exécutez une compresse après avoir posté, voici à quoi ressemble l'arborescence:

Pouvez-vous annuler la réconciliation après la compression? Eh bien, dans ce cas, non . La compresse a soufflé toute cette branche, vous ne pouvez donc pas annuler - ces données ont été supprimées. S'il y avait eu une autre version nommée sur cette branche, alors la compresse n'aurait pas détruit cette branche. J'espère que maintenant cela a du sens.

Alors, tu devrais faire ça? Selon vous, si vous ne savez pas ce que vous faites, vous pouvez facilement perdre des données après une compression.

Il existe un outil appelé Geodatabase Toolset (GDBT), qui est un plugin pour ArcCatalog. Il visualise la lignée d'état et les versions:

Téléchargez GDBT ici

À moins de connaître la version et la base de données. voici quelques informations initiales qui vous aideront.
Administrateur de base
Voici quelques informations sur les enregistrements et les publications.
Donc, si vous appliquez ces concepts et utilisez la commande de changements de version, vous avez toujours la possibilité de rejeter ces modifications lorsque vous enregistrez et publiez par défaut.

Vous n'avez pas trois copies de la même base de données.
Vous en avez un exemplaire avec des versions.
Si vous administrez cette base de données, vous devez vraiment passer du temps (peut-être même de l'argent) et vous familiariser avec tout cela.
Les flux de travail d'édition versionnés de la classe esri pour la géodatabase multi-utilisateurs sont gratuits et en aideront certains.
Mais le monte complet serait ce que je recommande pour une personne administrant tout type de flux de travail d'édition sde versionné.
Cette classe est géniale! pour comprendre les workflows d'édition avec version pour la géodatabase multi-utilisateurs .

J'ai un moyen "rapide et sale". Basculez vers la version par défaut et modifiez quelque chose sur le polygone qui a été supprimé. Ensuite, lorsque vous vous rapprocherez de la valeur par défaut, vous obtiendrez un conflit. Cliquez avec le bouton droit sur le conflit et dites-lui d'utiliser l'état de pré-réconciliation. Ça marche pour moi.

Oui, vous pouvez le faire, mais vous devrez le faire en utilisant SQL.

JE NE CONDONNE PAS CELA, FAITES-LE À VOS PROPRES RISQUES. TOUJOURS SAUVEGARDER VOS DONNÉES AVANT DE MODIFIER SDE MANUELLEMENT.

Vous pouvez interroger la table sde.versions pour obtenir l'état_id de la version que vous avez publiée avec les modifications que vous souhaitez annuler. Ensuite, vous pouvez accéder aux tables A et D et supprimer les entrées qui correspondent à state_id.

    SELECT *
    FROM SDE.VERSIONS
    WHERE NAME = 'Version of interest';

Vous avez maintenant le state_id d'intérêt. Vous devez maintenant trouver les tables A et D pour la classe d'entités. Pour ce faire, vous interrogez la table_registry. La valeur sera le registration_id. Donc, pour obtenir les tables A et D, ajoutez simplement registration_id aux A et D.

    REGISTRATION_ID = 1
    A table would be A1
    D table would be D1

Ensuite, interrogez simplement les tables A et D et supprimez les entrées qui ont le state_id de la requête ci-dessus.

Pour en savoir plus sur les relations parent-enfant, il vous suffit d'effectuer une requête dans les tableaux sde suivants.

    state_lineages
    versions
    states

Tous ont des relations et devraient vous aider à suivre la balle qui rebondit.

Il n'est pas possible d'annuler les modifications une fois qu'elles ont été publiées d'une version enfant vers la version parent. Voir: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

L'opération de publication ne peut pas être annulée, car vous appliquez des modifications à une version que vous n'êtes pas en train de modifier.

Vous pouvez consulter les modifications apportées dans chaque version au cours du processus de rapprochement - ce serait votre chance de rejeter certaines modifications. Le processus de réconciliation est expliqué ici .

Oui, comme d'autres l'ont dit, la réponse courte est non.

Le versionnage SDE est si prometteur, mais il est regrettable que son flux de travail suppose uniquement un changement en avant des fonctionnalités.

Le contrôle de version complet dans SDE offrirait des outils qui-

• Permet la restauration (au niveau de la fonctionnalité) et l'acceptation / le rejet
• Autoriserait les annulations
• Et permettrait l'annulation des états précédents (c'est-à-dire à partir de la stat 3, annuler les changements de l'état 1 mais garder les changements de l'état 2).

Ce serait comme un système de gestion des versions de contrôle de code source SVN mais pour les caractéristiques spatiales.

La réponse simple est non.

L'intention de publier une version est de valider ces modifications dans la version cible.

La restauration est effectuée en ne publiant pas la version (et il est recommandé de supprimer ces versions abandonnées).

Lors de l'édition de la version, l'application d'édition (par exemple ArcMap) peut fournir différents niveaux de «défaire» et l'utilisateur peut choisir d'enregistrer / ne pas enregistrer ces modifications dans la version en cours d'édition.

Mais après avoir posté sur une cible (par exemple sde.default), la seule façon d'annuler est via des hacks vers les tables système sde.