ArcSDEを使用したバージョン管理で、投稿された編集をキャンセルまたは拒否できるのはいつですか？

ArcGIS 9.3.1を使用しており、バージョン対応登録済みのSDEジオデータベース（1つのポリゴンフィーチャクラス）で作業しようとしています。私はバージョン管理に慣れていないのですが、基本的な機能のいくつかをまだ解明しようとしています。これまでのところ、親バージョンに投稿された特定の編集を「キャンセル」または「拒否」できるかどうかを発見できませんでした。

たとえば、バージョン付きとして登録されたときに作成された元のSDE.DEFAULT、SDE.QA（品質保証用）と呼ばれるデフォルトの子バージョン、およびSDEと呼ばれるQAの子バージョンの3つのバージョンがあるとします。 .Edit1（編集が最初に行われる場所）。SDE.Edit1の特定の機能が編集された場合（たとえば、シンプルにするために、1つのポリゴンが追加され、1つのポリゴンが削除されたとしましょう）後でこの変更を元に戻す方法はありますか？この質問をフォローアップすると、一部の変更のみを拒否できますか？たとえば、最初のポリの追加は受け入れますが、2番目のポリの削除は拒否しますか？

私の知る限り、編集が親バージョンに投稿されると、これらの変更はすべて親バージョンの「永続的な」（より良い言葉がないため）部分になります。これらの変更はすべて「ADD」テーブルと「DELETE」テーブル（「デルタ」テーブルと呼ばれることもあります）の2つのテーブル内にすべて記録され、実際には元のFC自体を変更しないという事実を認識しています。これらのデルタテーブルを手動で変更することを検討しましたが、適切な解決策ではない可能性があることを知るために、それに対して警告する十分な人が見つかりました。

おそらく、多少の作業が必要なのはバージョン管理についての私の理解ですが、変更を拒否したり、変更が投稿された後に元に戻す方法を見つけることができなかったようです。これは、エラーを含む投稿を取り消す方法がないことを意味するため、私には奇妙に思えます。また、これらのバージョンの系統（つまり、どのバージョンがどの親の子であるか）を追跡する方法を見つけることもできないようです。このトピックについては、ArcSDEの理解に役立つ（そしておそらくこれらの質問のいくつかに答える）特に有用なArcSDEリファレンス（リンク、記事、書籍など）を知っている人がいれば幸いです。 ！

これまでの回答は役に立ちましたが（リンクをありがとう）、私の質問の核心に対する答えがまだ見つかりません。繰り返しますが、おそらくそれは私自身の状況に対する誤解です。私が知りたいことは次のとおりです。

あなたは（逆の、I平均で逆にすることができ、アンドゥそれは親バージョンの子バージョンから作られた後、ポスト）？このシナリオでは、親はSDE.DEFAULTバージョンである場合がありますが、そうである必要はありません。さらに良いことに、投稿後に投稿の一部（たとえば、ポリゴンの1回の編集）を元に戻すことができるかどうかを知りたいですか？また、競合を検出する必要なくこれを実行できるかどうかも知りたいと思います。

この質問に対する明確な答えが見つからないという事実（つまり、「はい」または「いいえ」）がどこにも文書化されているため、ArcSDEのバージョン管理に関する重要な何かを見逃していると思われます。また、AテーブルとDテーブルを手動で操作することも避けたいと思います。

あー 答えは本当に複雑なものであり、ArcSDEのバックグラウンドを大量に必要とするため、できるだけ簡潔にするようにします。

注：私は、ESRIサイトで見つけることができる非常に素晴らしいバージョン管理ホワイトペーパーの図を参照します。バージョン管理を扱っている場合は、徹底的に読むことを強くお勧めします。

次に、状態（つまり、状態ツリーのノード）と名前付きバージョン（つまり、状態を指すラベル）の関係を理解する必要があります。

典型的なデータベースは、次の状態図のようになります。

ここでは、データベースに4つのバージョン（バージョンA、バージョンB、バージョンC、およびデフォルト）があります。しかし、おそらく、私は自分より少し先に進んでいます。状態とは何かから始めましょう。

状態は、「トランザクション」、つまり1つまたは複数のテーブルに対する複数の編集を含む論理ユニットと考えることができます。「Feature Class A」への2つの挿入、「Feature Class B」からの削除、および「Feature Class X」への変更（実質的に削除+挿入）を含めることができます。すべてが1つにグループ化されました。

状態ID 0から始まる、小さくシンプルなArcSDE状態図を見てみましょう。

状態0で開始し、編集操作で1つまたは複数のテーブルを編集する場合、子状態1を作成し、それを現在のアクティブな状態idにします。編集の別の後続のグループは、子状態2を作成します。元に戻す場合は、状態IDを変更する必要はありません。現在のアクティブ状態IDを1または0に変更するだけですどれくらい前に戻りたいか）。やり直しは反対です-現在のアクティブな状態IDを前方に移動するだけ-必要なだけ前方に移動します。

これが、ArcSDEバージョン管理で元に戻す/やり直しが機能する方法です。

OK 編集を永続的にしたい（つまり、保存したい）としましょう。あなたは何をしなければなりませんか？保存とは、バージョンラベルを取得して特定の状態に移行することです。スタンプを押して、「これがバージョンAのように見える必要がある」と言っているようなものです。したがって、最初の図を振り返ると、4つの名前付きバージョンがあることがわかります。

• バージョンBは状態ID 1を指します
• バージョンAは状態ID 3を指します
• バージョンCは状態ID 5を指します

• バージョン "SDE.DEFAULT"は状態ID 4を指します

  この図は、一般的な信念にもかかわらず、それらが持つ論理的な親子関係については何も語っていないことに注意してください。最初の図の論理的な親子関係は、効果的に次のようになります。

これは、ArcMap / ArcCatalogに表示される親子関係です。目的は、どのバージョンに対してリコンサイルできるかを制限することです。この時点で、（当然のことながら）自問自答することができます。なぜこれが必要なのでしょうか？その答えは、ワークフローのバージョン管理にあります。結局のところ、人々はかなり長い間バージョニングを使用しており、これらを構成する方法がいくつかありますが、今日はあなたの質問に答えたいので、それは別の日のトピックです:)

次へ...

さて、この名前付きバージョンは他に何をしますか？まあ、それらは圧縮と呼ばれるこのプロセスの動作に影響します。

圧縮とは、必要ではないかもしれない中間状態を取得し、不要なものを削除し、それらを結合することです。ArcCatalogを使用してArcSDE圧縮操作をトリガーし、それを1つずつ実行するサービスをセットアップできます。一部のArcMap編集操作は、ミニ圧縮操作をトリガーします（使用されている小さなブランチのみ）。

左側の図は、圧縮される前の状態ツリーを示し、右側の図は、圧縮された直後の状態ツリーを示しています。

理解すべき重要な概念（質問に最終的に回答したら参照します）は、ラベル（名前付きバージョン）が指定されている状態を除き、すべての状態が圧縮される可能性があるということです。

圧縮の前に、余分な-不要な状態があることがわかります。実際、[3,4,5]ブランチ全体が削除されました。5に名前付きバージョンがあった場合、最終結果は大きく異なります。

圧縮操作は、不要になったレコードを削除してデータベースのスペースを節約するためにあります。

OK

理解する必要がある最後の概念は、調整です。これは、2つのブランチを1つに効果的にマージします。

最初の図に戻りましょう。バージョンAをSDE.DEFAULTに一致させたいとします。

要約しましょう：さまざまな状態IDを指す4つの名前付きバージョン。したがって、最初に行う必要があるのは、ターゲットバージョンの下に子状態を作成することです。したがって、この例では、状態id 4の下に子状態を作成し、その状態id 20を呼び出します。

次のステップは、両方のバージョン間の差異を計算することです（詳細はこの投稿には長すぎますが、差異カーソルを使用して完了したことを伝えることができます）。次に、それらの差異を新しい状態ID 20（青い線）に適用します。

さらに編集を行うことを決定したか、競合を検出し、あるバージョンまたは別のバージョンから行を選択しているとします。関係ありません。これらは単なる新しい編集であり、マージしたブランチの下に子ステートがあるため、編集操作内で実行されます。この例では、調整後にさらに2つの連続した編集グループを作成しました。

素敵。

そのため、バージョンを「投稿」する準備ができたと言います。どういう意味ですか？これは、ラベルを取得して、同じ状態IDを指すようにするだけです。ここでは、バージョンAをSDE.DEFAULTに投稿します。これは次のようになります。

TADAAA！そのため、バージョンAとSDE.DEFAULTは同じ状態IDを指しているため、同じように見えます。

OK、そう今私は最終的にあなたの質問に答えることができます。

投稿を取り消すことができますか？ArcGISのドキュメントには、「いいえ」と書かれています-混乱しないでください。このロジックをいじるので、やらないでください。何をしているかわからない場合は、データが破損する可能性があります。

しかし、実際には、ArcSDEバージョン管理テーブルの 1つであるVERSIONSテーブルを1回更新し、ラベルのエントリ（名前付きバージョン）を変更するだけです。この例では、状態ID 21をポイントし、編集操作全体を元に戻しました。3に設定すると、調整全体が元に戻ります。5に設定すると、今はまったく別の場所にいます。競合があるかどうかは関係ありません。

もちろん、これは圧縮が行われていないことを前提としています。SDEテーブルを更新しているのとまったく同時に圧縮が行われている場合を考えてみましょう。投稿した後にあなたまたは他の誰かが圧縮を実行する場合、これはツリーのように見えることを覚えておいてください：

圧縮後に調整を元に戻すことはできますか？まあ、この場合、いいえ。圧縮はそのブランチ全体を吹き飛ばしたので、元に戻すことはできません-そのデータは削除されました。そのブランチに別の名前付きバージョンがあった場合、圧縮はそのブランチを破壊しませんでした。今ではこれが理にかなっていることを願っています。

だからあなたはこれをする必要がありますか？あなた次第ですが、何をしているのかわからない場合は、圧縮後に簡単にデータを失うことができます。

GeoCatalogのプラグインであるジオデータベースツールセット（GDBT）と呼ばれるツールがあります。状態の系統とバージョンを視覚化します。

ここからGDBTをダウンロードしてください

バージョンとデータベースを知らない。ここに役立つ初期情報があります。
基本的な管理者
ここにrecとpostに関する情報
があります。したがって、これらの概念を適用してバージョン変更コマンドを使用すると、デフォルトにrecとpostするときにこれらの変更を拒否する機会があります。

同じデータベースの3つのコピーはありません。
バージョン付きのコピーが1つあります。
このdbを管理している場合は、本当に時間を費やし（おそらくお金も）、これらすべてに慣れる必要があります。マルチユーザー
ジオデータベースのesriクラスのバージョン付き編集ワークフローは無料で、一部のユーザーに役立ちます。
しかし、完全なモンテは、あらゆる種類のバージョン付きsde編集ワークフローを管理する人にお勧めです。
そのクラスは素晴らしいです！マルチユーザージオデータベースのバージョン付き編集ワークフローを理解する ため。

私は「迅速で汚い」方法を持っています。oveをデフォルトバージョンに切り替えて、削除されたポリゴンに関する何かを編集します。その後、デフォルトに調整すると、競合が発生します。競合を右クリックして、事前調整状態を使用するように指示します。わたしにはできる。

はい、できますが、SQLを使用して行う必要があります。

私はこれを無視し、あなた自身の責任でこれを行います。SDEを手動で編集する前に、常にデータをバックアップしてください。

sde.versionsテーブルを照会して、取り消したい変更を加えて投稿したバージョンからstate_idを取得できます。その後、AテーブルとDテーブルに移動し、state_idに一致するエントリを削除できます。

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

これで、対象のstate_idが得られました。次に、フィーチャクラスのAテーブルとDテーブルを見つける必要があります。これを行うには、table_registryを照会します。値はregistration_idになります。AとDのテーブルを取得するには、registration_idをAとDに追加するだけです。

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

次に、AテーブルとDテーブルの両方をクエリし、上記のクエリからstate_idを持つエントリを削除します。

親と子の関係の詳細を調べるには、次のsdeテーブルからクエリを実行します。

    state_lineages
    versions
    states

これらはすべて関係があり、跳ねるボールを追跡するのに役立ちます。

子バージョンから親バージョンにポストされた編集を元に戻すことはできません。参照：http : //help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

現在編集していないバージョンに変更を適用しているため、ポスト操作を元に戻すことはできません。

調整プロセス中に各バージョンで行われた編集を確認できます。これは、特定の編集を拒否するチャンスです。ここでは、調整プロセスについて説明します。

はい、他の人は短い答えはノーだと言ったように。

SDEのバージョン管理は非常に有望ですが、そのワークフローが機能の前方変更のみを想定しているのは残念です。

SDEの完全な機能を備えたバージョン管理では、次のようなツールが提供されます。

• （機能レベルの）ロールバックと受け入れ/拒否を許可します
• 元に戻すことができます
• また、以前の状態の取り消しを許可します（つまり、stat 3から開始し、状態1からの変更を取り消しますが、状態2からの変更は保持します）。

これは、SVNのソースコード管理バージョン管理システムのようなものですが、空間的な機能のためのものです。

簡単な答えはNOです。

バージョンを投稿する意図は、それらの編集をターゲットバージョンにコミットすることです。

ロールバックは、バージョンを投稿しないことで実現されます（そのような放棄されたバージョンを削除することをお勧めします）。

バージョンの編集中、編集アプリケーション（ArcMapなど）はさまざまなレベルの「元に戻す」を提供し、ユーザーは編集中のバージョンにそのような編集を保存するかどうかを選択できます。

ただし、ターゲット（例：sde.default）に投稿した後、元に戻す唯一の方法は、sdeシステムテーブルへのハックを経由することです。