Cuando el control de versiones con ArcSDE puede cancelar o rechazar las ediciones publicadas?

Estoy usando ArcGIS 9.3.1 e intento trabajar con una geodatabase SDE (con una clase de entidad poligonal) que ya ha sido registrada como versionada. Soy nuevo en el control de versiones y todavía estoy tratando de descubrir algunas de sus funciones básicas. Hasta ahora, no he podido descubrir si es posible "cancelar" o "rechazar" ciertas ediciones una vez que se han publicado en una versión principal.

Por ejemplo, supongamos que tenemos tres versiones: el SDE.DEFAULT original que se creó cuando se registró como versionado, una versión secundaria del valor predeterminado llamada SDE.QA (para Garantía de calidad) y una versión secundaria del control de calidad llamado SDE .Edit1 (donde se realizan las ediciones por primera vez). Si se editaran ciertas características de SDE.Edit1 (por ejemplo, para simplificarlo, digamos que se agregó un polígono y se eliminó uno) y luego SDE.Edit1 se concilió con el SDE.QA y posteriormente se publicó en SDE.QA, ¿Alguna forma de deshacer este cambio más tarde? Siguiendo esta pregunta, ¿sería posible rechazar solo algunos cambios? Por ejemplo, ¿acepta agregar el primer poli, pero rechaza eliminar el segundo poli?

Por lo que puedo decir, una vez que las ediciones se han publicado en la versión principal, todos estos cambios son ahora una parte "permanente" (por falta de una palabra mejor) de la versión principal. Soy consciente del hecho de que todos estos cambios se registran en dos tablas, las tablas "AGREGAR" y "BORRAR" (a menudo denominadas tablas "delta"), y en realidad no cambian el FC original. Pensé en buscar alterar manualmente estas tablas delta, pero encontré suficientes personas advirtiendo contra eso para saber que probablemente no sea la solución correcta.

Quizás es mi comprensión de las versiones lo que necesita algo de trabajo, pero parece que no pude encontrar una manera de rechazar un cambio o deshacer un cambio una vez que se ha publicado. Esto me parece extraño, ya que esto significaría que no hay forma de deshacer una publicación que contenga un error. Tampoco parece que pueda encontrar una manera de rastrear el linaje de estas versiones (es decir, qué versión es hija de qué padre). Mientras estoy en el tema, si alguien pudiera conocer alguna referencia de ArcSDE particularmente útil (enlaces, artículos, libros, etc.) que pueda ayudarme a comprender ArcSDE (y tal vez responder algunas de estas preguntas), sería muy apreciado !

Aunque las respuestas hasta ahora han sido útiles (gracias por los enlaces), todavía no puedo encontrar una respuesta al núcleo de mi pregunta. De nuevo, tal vez es mi propio malentendido de la situación. Esto es lo que quiero saber:

¿Puedes revertir (por reverso, quiero decir deshacer ) una publicación una vez que se ha hecho de una versión secundaria a una versión primaria? En este escenario, el padre puede ser, pero no tiene que ser, la versión SDE.DEFAULT. Aún mejor, me gustaría saber si puede invertir una parte de una publicación (por ejemplo, una sola edición en un polígono), después de que se haya publicado. También me gustaría saber si esto se puede hacer sin la necesidad de haber detectado ningún conflicto.

El hecho de que no pueda encontrar una respuesta clara a esta pregunta (es decir, "sí" o "no") documentada en ninguna parte me hace pensar que me falta algo importante sobre el control de versiones en ArcSDE. También preferiría evitar manipular las tablas A y D manualmente.

Ugh La respuesta es realmente complicada y requiere muchos antecedentes de ArcSDE, por lo que intentaré ser lo más breve posible.

Tenga en cuenta que me referiré a algunos diagramas del documento técnico de versiones súper impresionante que puede encontrar en el sitio de ESRI . Si se trata de versiones, le recomiendo que lo lea detenidamente.

Luego, debe comprender cuál es la relación entre un estado (es decir, un nodo del árbol de estado) y una versión con nombre (es decir, una etiqueta que apunta a un estado).

Una base de datos típica puede verse como el diagrama de estado a continuación:

Aquí, tiene cuatro versiones en la base de datos (Versión A, Versión B, Versión C y POR DEFECTO). Pero quizás, me estoy adelantando un poco. Comencemos con lo que es un estado .

Puede pensar en un estado como una "transacción", una unidad lógica que contiene varias ediciones en una o varias tablas. Puede incluir dos inserciones en "FeatureClass A", una eliminación de "Feature Class B" y una modificación (efectivamente, delete + an insert) a "Feature Class X". Todos agrupados en uno.

Veamos un diagrama de estado de ArcSDE pequeño y simple que comienza en la identificación de estado 0:

Si comienza en el estado 0 y realiza modificaciones en una o varias tablas en una operación de edición, creará un estado secundario 1 y lo convertirá en el ID de estado activo actual . Otro grupo posterior de ediciones creará el estado secundario 2. Si desea deshacer, no necesita modificar la identificación del estado de ninguna manera; todo lo que necesita hacer es cambiar la identificación del estado activo actual a 1 o 0 (dependiendo qué tan lejos quieres ir). Un rehacer es lo contrario: simplemente mueva el ID del estado activo actual hacia adelante, tan lejos como desee.

Así es como funciona deshacer / rehacer en el control de versiones de ArcSDE.

OK, sigue adelante. Digamos que desea hacer una edición permanente (es decir, desea guardar). ¿Que tienes que hacer? Bueno, guardar es solo tomar una etiqueta de versión y avanzarla a un estado en particular. Algo así como estamparlo y decir "así es como debe verse la Versión A". Entonces, si observa el primer diagrama, verá que tiene cuatro versiones con nombre .

• La versión B apunta al ID de estado 1
• La versión A apunta al ID de estado 3
• La versión C apunta al ID de estado 5

• La versión "SDE.DEFAULT" apunta al ID de estado 4

  Tenga en cuenta que este diagrama, a pesar de la creencia popular, no le dice nada sobre la relación lógica padre-hijo que tienen. La relación lógica padre-hijo para el primer diagrama podría verse así:

Esta es la relación padre-hijo que ve en ArcMap / ArcCatalog. Su propósito es restringir con qué versiones se puede reconciliar. En este punto, podrías (con razón) preguntarte, ¿por qué demonios necesito esto? La respuesta está en los flujos de trabajo de versiones . Resulta que las personas han estado usando el control de versiones durante bastante tiempo y hay algunas formas preferidas de cómo estructurarlas, pero ese es un tema para otro día ya que quiero responder a su pregunta hoy :)

Continuando ...

Bien, ¿qué más hacen estas versiones con nombre? Bueno, afectan cómo se comporta este proceso llamado compresa .

Comprimir se trata de obtener estados intermedios que pueden no ser necesarios y eliminar los innecesarios, así como combinarlos. Puede activar la operación de compresión ArcSDE a través de ArcCatalog, configurar un servicio que lo haga cada cierto tiempo, y algunas operaciones de edición de ArcMap activarán operaciones de mini-compresión (es decir, solo para ramas pequeñas que se están utilizando).

El diagrama de la izquierda muestra un árbol de estado antes de que se comprima, y ​​el de la derecha lo muestra justo después de que se comprime:

Un concepto importante para entender (que me referiré a usted una vez que finalmente pueda responder a su pregunta) es que cada estado es un candidato potencial para ser comprimido, excepto los estados que tienen etiquetas (es decir, versiones con nombre) apuntadas a ellos.

Puede ver que antes de la compresa hay algunos estados adicionales innecesarios. De hecho, se eliminó toda la rama [3,4,5]. Si hubiera habido una versión con nombre en 5, el resultado final habría sido muy diferente.

Las operaciones de compresión están ahí para ahorrar espacio en su base de datos al eliminar registros que ya no necesita.

OK, sigue adelante.

El último concepto que debe comprender es la reconciliación , que es la fusión efectiva de dos ramas en una.

Así que volvamos a nuestro primer diagrama. Supongamos que desea conciliar la Versión A con SDE.DEFAULT.

Recapitulemos: cuatro versiones con nombre que apuntan a varios identificadores de estado. Entonces, lo primero que tenemos que hacer es crear un estado secundario en la versión de destino, de modo que creamos un estado secundario en la identificación de estado 4, en nuestro ejemplo, llamo a esa identificación de estado 20.

El siguiente paso es calcular las diferencias entre ambas versiones (los detalles son demasiado largos para esta publicación, pero puedo decirle que se hicieron con cursores de diferencia ) y luego aplicar esas diferencias a esa nueva identificación de estado 20 (línea azul).

Supongamos que decide hacer más ediciones o que encontró conflictos y está eligiendo filas de una versión u otra. No importa. Esas son solo ediciones nuevas, y se realizan dentro de una operación de edición, como estados secundarios debajo de la rama que fusionó. En este ejemplo, he realizado dos grupos más de ediciones consecutivas después de la conciliación.

Encantador.

Ahora diga que está listo para " publicar " la versión. Qué significa eso? Eso es solo agarrar las etiquetas y apuntarlas al mismo ID de estado. Aquí, voy a publicar la Versión A en SDE.DEFAULT. Esto es lo que parece:

TADAAA! Así que ahora la Versión A y SDE.DEFAULT apuntan al mismo ID de estado, y por lo tanto se ven iguales.

Bien, ahora puedo finalmente responder tu pregunta.

¿Puedes deshacer una publicación? La documentación de ArcGIS le dirá que no , no se meta con eso. No lo hagas, porque estarás jugando con esta lógica, y si no sabes lo que estás haciendo, puedes corromper tus datos.

Pero en verdad, todo lo que se necesita es hacer una actualización de una de las tablas de versiones de ArcSDE : la tabla VERSIONS y modificar la entrada de la etiqueta (también conocida como versión con nombre). En nuestro ejemplo, señale la identificación de estado 21, y acaba de deshacer toda la operación de edición. Póngalo en 3, y simplemente deshizo toda la conciliación. Póngalo en 5, y ahora está en un lugar completamente diferente. Ya sea que haya o no conflictos, es irrelevante.

Por supuesto, esto supone que no ha ocurrido una compresa. Consideremos el caso en el que la compresión está ocurriendo exactamente al mismo tiempo que actualiza la tabla SDE. Recuerde, si usted u otra persona ejecuta una compresa después de publicar esto, así es como se ve el árbol:

¿Puedes deshacer la conciliación después de la compresa? Bueno, en este caso, no . La compresa ha volado toda esa rama, por lo que no puede deshacerla: esos datos se han eliminado. Si hubiera habido otra versión con nombre en esa rama, entonces la compresa no habría destruido esa rama. Espero que a estas alturas esto tenga sentido.

Entonces, ¿deberías hacer esto? Depende de usted, si no sabe lo que está haciendo, puede perder datos fácilmente después de una compresa.

Existe una herramienta llamada Geodatabase Toolset (GDBT), que es un complemento para ArcCatalog. Visualiza el estado del linaje y las versiones:

Descargue GDBT aquí

A falta de conocer la versión y db. Aquí hay información inicial que lo ayudará.
Administrador básico
Aquí hay información sobre rec y post
Así que si aplica estos conceptos y usa el comando de cambios de versión , todavía tiene la oportunidad de rechazar esos cambios cuando rec y post por defecto.

No tiene tres copias de la misma base de datos.
Tienes una copia con versiones.
Si está administrando esta base de datos, realmente debería pasar el tiempo (tal vez incluso dinero) y familiarizarse con todo esto.
Los flujos de trabajo de edición versionada de la clase esri para la geodatabase multiusuario son gratuitos y ayudarán a algunos.
Pero el monte completo sería lo que recomiendo para una persona que administra cualquier tipo de flujo de trabajo de edición sde versionado.
Esa clase es genial! para la comprensión de versionado Edición de flujos de trabajo para la base de datos geográficos multiusuario .

Tengo una forma "rápida y sucia". Cambie a la versión predeterminada y edite algo sobre el polígono que se eliminó. Luego, cuando se reconcilie con el valor predeterminado, obtendrá un conflicto. Haga clic derecho en el conflicto y dígale que use el estado de preconciliación. Esto funciona para mi.

Sí, puedes hacer esto, pero tendrás que hacerlo usando SQL.

NO CONDONE ESTO, HAGA ESTO A SU PROPIO RIESGO. Siempre haga una copia de seguridad de sus datos antes de editar SDE manualmente.

Puede consultar la tabla sde.versions para obtener el state_id de la versión que publicó con los cambios que desea deshacer. Luego puede ir a las tablas A y D y eliminar las entradas que coinciden con state_id.

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

Ahora tiene el state_id de interés. Ahora necesita encontrar las tablas A y D para la clase de entidad. Para ello, consulta el table_registry. El valor será el registro_id. Entonces, para obtener las tablas A y D, simplemente agregue el valor de registro a las A y D.

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

Luego, solo consulte las tablas A y D y elimine las entradas que tienen el state_id de la consulta anterior.

Para obtener más información sobre las relaciones padre e hijo, solo consulte en las siguientes tablas sde.

    state_lineages
    versions
    states

Todos estos tienen relaciones y deberían ayudarte a seguir la pelota que rebota.

No es posible deshacer las ediciones una vez que se han publicado desde una versión secundaria a la versión principal. Ver: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//00270000001s000000.htm

La operación de publicación no se puede deshacer, ya que está aplicando cambios a una versión que no está editando actualmente.

Puede revisar las ediciones realizadas en cada versión durante el proceso de reconciliación; esta sería su oportunidad de rechazar ciertas ediciones. El proceso de reconciliación se explica aquí .

Sí, como otros han dicho, la respuesta corta es no.

El control de versiones de SDE es muy prometedor, pero es desafortunado que su flujo de trabajo solo suponga un cambio directo en las características.

El control de versiones con todas las funciones en SDE ofrecería herramientas que:

• Permite revertir (nivel de función) y aceptar / rechazar
• Permitiría deshacer
• Y permitiría deshacer los estados anteriores (es decir, a partir de la estadística 3, deshacer los cambios del estado 1 pero mantener los cambios del estado 2).

Esto sería como un sistema de control de versiones de código fuente SVN pero para características espaciales.

La respuesta simple es no.

La intención de publicar una versión es confirmar esas ediciones en la versión de destino.

La reversión se logra al no publicar la versión (y es una buena práctica eliminar cualquier versión abandonada).

Mientras edita la versión, la aplicación de edición (por ejemplo, ArcMap) puede proporcionar varios niveles de 'deshacer' y el usuario puede elegir guardar / no guardar tales ediciones en la versión que se está editando.

Pero después de publicar en un destino (por ejemplo, sde.default), la única forma de deshacer es mediante hacks en las tablas del sistema sde.