Тьфу. Ответ действительно сложный, требующий большого опыта работы с ArcSDE, поэтому я постараюсь быть максимально кратким.
Обратите внимание, что я собираюсь сослаться на некоторые диаграммы из супер-классного документа по версиям, который вы можете найти на сайте ESRI . Если вы имеете дело с версионированием, я настоятельно рекомендую вам внимательно прочитать его.
Затем вам необходимо понять, какова связь между состоянием (то есть узлом из дерева состояний) и именованной версией (то есть меткой, указывающей на состояние).
Типичная база данных может выглядеть как диаграмма состояний ниже:
Здесь у вас есть четыре версии в базе данных (версия A, версия B, версия C и DEFAULT). Но, возможно, я немного опередил себя. Давайте начнем с того, что такое государство .
Вы можете думать о состоянии как о «транзакции» - логической единице, которая содержит несколько правок одной или нескольких таблиц. Он может включать две вставки в «FeatureClass A», удаление из «Feature Class B» и изменение (фактически удаление + вставка) в «Feature Class X». Все сгруппированы в одно.
Давайте рассмотрим небольшую простую диаграмму состояний ArcSDE, которая начинается с идентификатора состояния 0:
Если вы начинаете с состояния 0 и вносите изменения в одну или несколько таблиц в операции редактирования, вы создадите дочернее состояние 1 и сделаете его текущим идентификатором активного состояния . Другая последующая группа изменений создаст дочернее состояние 2. Если вы хотите отменить, вам не нужно каким-либо образом изменять идентификатор состояния - все, что вам нужно сделать, это изменить текущий идентификатор активного состояния на 1 или 0 (в зависимости от как далеко назад вы хотите пойти). Повторить это наоборот - просто переместить текущий идентификатор текущего состояния вперед - так далеко, как вы хотите.
Вот как работает отмена / повтор в версиях ArcSDE.
ОК, двигаясь дальше. Скажем, что вы хотите сделать редактирование постоянным (т.е. вы хотите сохранить). Что ты должен делать? Что ж, сохранение - это просто захват метки версии и ее перемещение в определенное состояние. Вроде как штамповать его и говорить "вот как должна выглядеть Версия А". Итак, если вы оглянетесь на первую диаграмму, вы увидите, что она имеет четыре названные версии .
- Версия B указывает на идентификатор состояния 1
- Версия A указывает на идентификатор состояния 3
- Версия C указывает на идентификатор состояния 5
Версия "SDE.DEFAULT" указывает на идентификатор состояния 4
Обратите внимание, что эта диаграмма, несмотря на распространенное мнение, не говорит вам ничего о логических отношениях между родителями и детьми, которые они имеют. Логические отношения родитель-потомок для первой диаграммы могут выглядеть так:
Это отношение родитель-потомок, которое вы видите в ArcMap / ArcCatalog. Его цель - ограничить, с какими версиями вы можете согласовать. В этот момент вы могли бы (по праву) спросить себя, какого черта мне это нужно? Ответ заключается в рабочих процессах управления версиями . Оказывается, люди используют версионирование уже довольно давно, и есть некоторые предпочтительные способы их структурирования, но это тема другого дня, так как я хочу ответить на ваш вопрос сегодня :)
Двигаясь дальше ...
Хорошо, так что еще делают эти именованные версии? Ну, они влияют на то, как ведет себя этот процесс, называемый сжатием .
Compress - это захват промежуточных состояний, которые могут быть не нужны, и удаление ненужных, а также их объединение. Вы можете запустить операцию сжатия ArcSDE через ArcCatalog, настроить сервис, который делает это каждый раз, и некоторые операции редактирования ArcMap будут запускать операции мини-сжатия (т. Е. Только для небольших используемых веток).
Диаграмма слева показывает дерево состояний до его сжатия, а справа - сразу после сжатия:
Важная концепция, которую нужно понять (на которую я буду ссылаться после того, как я наконец получу ответ на ваш вопрос), состоит в том, что каждое отдельное состояние является потенциальным кандидатом на сжатие, за исключением состояний, на которые указывают метки (то есть именованные версии).
Вы можете видеть, что перед сжатием есть некоторые лишние ненужные состояния. Фактически, вся [3,4,5] ветка была удалена. Если бы была названная версия на 5, конечный результат был бы совсем другим.
Операции сжатия предназначены для экономии места в вашей базе данных путем удаления записей, которые вам больше не нужны.
ОК, двигаясь дальше.
Последняя концепция, которую вам нужно понять, - это согласование, которое фактически объединяет две ветви в одну.
Итак, давайте вернемся к нашей самой первой диаграмме. Скажем, что вы хотите согласовать версию A с SDE.DEFAULT.
Напомним: четыре именованные версии, указывающие на различные идентификаторы состояния. Итак, первое, что нам нужно сделать, это создать дочернее состояние под целевой версией, поэтому мы создаем дочернее состояние под идентификатором состояния 4, в нашем примере я называю этот идентификатор состояния 20.
Следующим шагом является вычисление различий между обеими версиями (детали слишком длинны для этого поста, но я могу сказать, что они сделаны с помощью курсоров различий ), а затем применение этих различий к этому новому идентификатору состояния 20 (синяя линия).
Скажем, вы решили сделать больше правок или обнаружили конфликты и выбираете строки из одной или другой версии. Это не важно Это просто новые правки, которые выполняются внутри операции редактирования, как дочерние состояния под слитой ветвью. В этом примере я сделал еще две последовательные группы правок после согласования.
Прекрасный.
Так что теперь говорите, что вы готовы « опубликовать » версию. Что это значит? Это просто захват меток и указание их на один и тот же идентификатор состояния. Здесь я собираюсь опубликовать версию A в SDE.DEFAULT. Вот как это выглядит:
TADAAA! Так что теперь версии A и SDE.DEFAULT указывают на один и тот же идентификатор состояния, и поэтому они выглядят одинаково.
Хорошо, теперь я могу наконец ответить на ваш вопрос.
Вы можете отменить пост? Документация ArcGIS скажет вам нет - не связывайтесь с этим. Не делайте этого, потому что вы будете возиться с этой логикой, и если вы не знаете, что делаете, вы можете испортить ваши данные.
Но, по правде говоря, все, что нужно, это сделать одно обновление одной из таблиц версий ArcSDE - таблицы VERSIONS и изменить запись метки (называемой версией). В нашем примере укажите на идентификатор состояния 21, и вы только что отменили всю эту операцию редактирования. Установите его на 3, и вы просто отмените все согласование. Установите его на 5, и теперь вы находитесь в совершенно другом месте. Есть ли конфликты или нет, не имеет значения.
Конечно, это предполагает, что компресс не произошел. Давайте рассмотрим случай, когда сжатие происходит именно тогда, когда вы обновляете таблицу SDE. Помните, что если вы - или кто-то еще - выполняете сжатие после того, как вы разместили, то дерево выглядит так:
Можете ли вы отменить примирение после компресса? Ну, в этом случае нет . Сжатие уничтожило всю эту ветку, поэтому вы не можете отменить - эти данные были удалены. Если бы в этой ветви была другая именованная версия, то компресс не уничтожил бы эту ветку. Я надеюсь, что сейчас это имеет смысл.
Так ты должен сделать это? До вас, если вы не знаете, что делаете, вы можете легко потерять данные после сжатия.