Desarrollo independiente: maestría Gestión de modificaciones en varias réplicas: maestría

Debido a que los cambios se efectúan de forma independiente en varias réplicas, estos cambios pueden dar lugar a conflictos. En un entorno MultiSite, se realiza el seguimiento de los cambios y se evitan los daños en los datos con un esquema de derechos de modificación exclusivos denominado Maestría. La maestría determina cuándo un usuario de una réplica puede modificar datos.

Si el trabajo efectuado en diferentes réplicas es realmente independiente, el resultado será caótico. Suponga que la versión 17 de un elemento se crea en la rama principal en tres réplicas simultáneamente. ¿Cuál es la versión 17 real y qué le suceden a las demás versiones? Si se crea un registro SAMPL00001 en tres réplicas simultáneamente, resulta imposible determinar cuál es el registro real SAMPL00001 y qué le debe suceder a los otros dos registros.

A determinados objetos se les asigna una réplica maestra (o maestro). El maestro inicial de un objeto es la réplica en la que se crea el objeto y la maestría puede cambiarse posteriormente (consulte c_mng_mstrshp.htm). En general, un objeto sólo se puede modificar o suprimir en su réplica maestra.

Por ejemplo, cada tipo de ramificación tiene una réplica maestra. De forma predeterminada, puede crear o modificar una ramificación únicamente si la réplica actual controla el tipo de ramificación. En este ejemplo, el mandato no se ejecuta correctamente porque la réplica actual no controla el tipo de ramificación principal:
cleartool checkout –c "add new feature" v3.0plan.doc 
cleartool: Error: Unable to perform operation "checkout" in replica 
"sanfran_hub" of VOB "/vobs/doc".
cleartool: Error: Master replica of branch "/main" is "boston_hub".
cleartool: Error: Unable to check out "v3.0plan.doc".

Las réplicas, las VOB y la mayoría de los objetos en una VOB tienen una réplica maestra. Para obtener más información sobre cómo la maestría impide que los cambios den lugar a conflictos, consulte c_mstrshp_ovw.htm#sii-operation-48298.

La mayoría de los objetos en la base de datos de Rational ClearQuest tienen una réplica maestra.

Algunos conflictos son inevitables. Por ejemplo, se pueden crear objetos con el mismo nombre en dos o más réplicas VOB durante el mismo periodo de tiempo entre sincronizacionesse puede crear un usuario nuevo llamado jsmith en dos o más sitios durante el mismo periodo de tiempo entre sincronizaciones. Puede minimizar conflictos de este tipo estableciendo convenios de denominación de objetos, pero si se produce un conflicto, se maneja durante la importación de un paquete de actualización. Para obtener más información, consulte c_conflict_resl.htm.

Conceptos relacionados
Gestión de la maestría
Resolución de conflictos de objetos de base de datos

Comentarios