Sincronización y control de versiones
Este tema se aplica a ArcGIS for Desktop Standard y ArcGIS for Desktop Advanced exclusivamente.
La replicación de geodatabases utiliza el control de versiones durante el proceso de sincronización para las réplicas alojadas en geodatabases de ArcSDE. La excepción es cuando se está utilizando el archivado para realizar el seguimiento de cambios en una replicación unidireccional.
El control de versiones se utiliza para determinar los cambios a enviar y también al recibir cambios. A continuación se describe cómo se utiliza el control de versiones en cada uno de estos procesos:
Enviar cambios
Cuando una réplica envía cambios, ArcSDE determina qué ediciones enviar analizando la versión de réplica (se define durante la creación de la réplica) y algunas versiones de sistema. Este análisis puede filtrar para dejar fuera las ediciones ya enviadas durante sincronizaciones anteriores o determinar que algunos cambios deben enviarse de nuevo. Para las réplicas checkout en geodatabases de archivos o personales, se analiza una tabla interna que contiene todas las ediciones. Para la replicación unidireccional utilizando archivado, se analiza la clase de archivado para determinar qué cambios enviar.
Recibir cambios
Cuando una réplica recibe cambios, ocurre lo siguiente:
Primero, se aplican los cambios a la versión de sincronización. La versión de sincronización es un elemento secundario de la versión de réplica. Está diseñado para contener estos cambios temporalmente hasta que se concilien y se envíen a la versión de réplica. Para las réplicas bidireccionales y unidireccionales, es posible que la versión no se cree hasta el momento de la sincronización, mientras que para las réplicas checkout la versión se crea en el momento de la creación. En los diagramas siguientes, la versión de réplica podría ser DEFAULT o una versión con nombre.
A continuación, la versión de sincronización se concilia con la versión de réplica. El comportamiento en este paso depende del tipo de réplica:
- Réplicas bidireccionales: para las réplicas bidireccionales, puede haber conflictos durante la conciliación. Si hay conflictos, se utiliza una política de conciliación para determinar cómo gestionar los conflictos. Puede elegir entre políticas de conciliación automáticas y manuales durante la sincronización. Si no hay ningún conflicto, o una política de conciliación automática resuelve los conflictos, la versión de réplica se envía con la versión de sincronización.
- Réplicas checkout: para las réplicas checkout, la conciliación y el envío son opcionales y no se ejecutan de manera predeterminada. Si decide no conciliar ni enviar, los cambios permanecen en la versión de sincronización. Entonces puede conciliar y enviar manualmente en un momento posterior. Si decide conciliar y enviar, el comportamiento es igual que con réplicas bidireccionales.
- Réplicas unidireccionales: con las réplicas unidireccionales, los cambios en la versión de réplica siempre se sobrescriben, y nunca hay conflictos sin resolver. Cuando se utiliza un tipo de modelo simple, es posible que los datos de la réplica secundaria no estén versionados. Si es así, los cambios se aplican directamente a las tablas base y no se utiliza el control de versiones al recibir los cambios. Los cambios también se sobrescriben directamente para los casos donde la réplica secundaria está alojada en una geodatabase personal o de archivos.
 |
Una vez enviados los cambios a la versión de réplica, la versión de sincronización se elimina. Si elige una política de conciliación manual y hay conflictos, es decisión suya realizar la conciliación y el envío en un momento posterior. Para las réplicas bidireccionales, siempre que exista la versión de sincronización, la réplica se considera en conflicto. Mientras esté en conflicto, se puede recibir cambios, pero no enviarlos desde la réplica.
 |
Nota: