Implementando en su mayor parte los atómicos ClearCase.

Question

Tengo un proyecto en el que necesito realizar varias operaciones en una vista dinámica. Si alguna de esas operaciones falla, o aparece algún error en el programa, necesito poder anular las confirmaciones.

La forma más directa parece ser simplemente poner los comandos en una cola y luego, cuando mi programa termina de procesarse, ejecuta la cola. Sin embargo, me preocupa que algún evento excepcional interrumpa las confirmaciones y cause un conjunto de datos inconsistente en el servidor.

O, en otras palabras, estoy buscando una manera de crear un 'conjunto de cambios' de estilo svn en las vistas dinámicas de Clearcase. El lenguaje de script que estoy usando es Perl, si eso importa.

Ideas?

Answer 1

La atomicidad de la operación en ClearCase es a nivel de archivo, no hay un equivalente estricto de a svn changeset (es decir, una " revisión ").

Lo más cercano a un conjunto de cambios en ClearCase es la noción de actividad (en UCM), o un conjunto de etiquetas en una colección de archivos (una línea de base de UCM está más cerca, ya que representa etiquetas que no puede mover, en un conjunto de archivos predefinidos - componente UCM -)

Ahora, UCM o no, recomendaría:

• bloquear la rama en la que harás los checkins (de esa manera, el vob sigue siendo accesible, y nadie está tratando de agregar otras versiones en esa rama en particular durante su operación "atómica")
• hacer sus registros
• desbloquear la rama

En caso de problemas, mientras la rama aún está bloqueada, puede ' ct rmver ' las versiones agregadas. (Nota: para usar con cuidado: un rmver no se puede deshacer)

• Nota 1: si no está trabajando en UCM, tendrá que registrar todas las versiones registradas para poder revisarlas

• Nota2: cuando dije "bloquear la rama", quise decir, por supuesto: "bloquear para todos excepto para ti" ( -nusers yourLogin ). De esa manera, solo usted puede hacer checkins (que se aplican a todos los archivos de LATEST en la rama en la que está trabajando (principal u otro).

---

El problema, con este enfoque, es que los clientes (los otros usuarios con sus vistas dinámicas en la ÚLTIMA en la rama) verán durante su transacción atómica. < br> Dado que son vistas dinámicas , verán los archivos registrados mientras estos archivos se ingresan, uno por uno. Puede que no sea bueno, especialmente si hay 200 archivos y si todo el proceso lleva más de un minuto.

Una solución sería que las vistas del cliente configuren sus especificaciones de configuración de la siguiente manera:

element * .../myBranch/FREEZED_LATEST
element * .../myBranch/LATEST

Si no está realizando una confirmación atómica de conjunto de cambios, la etiqueta FREEZED_LATEST no existe, y todas las vistas del cliente se muestran MÁS RECIENTES, como deberían. Cualquier registro es inmediatamente visto por todos.
Pero durante tu compromiso atómico, podrías:

• primero establece una etiqueta FREEZED_LATEST en todos los archivos actuales (actualmente en LATEST, es decir)
  Eso significa que todos los clientes solo verán esas versiones específicas durante el compromiso atómico
• haga su proceso (hasta el final, o retroceda: de cualquier manera, la rama está bloqueada, y la especificación de configuración de los clientes sigue mostrando el mismo contenido "congelado")
• elimine la etiqueta FREEZED_LATEST (todos los clientes siguen viendo el último ÚLTIMO que resulta de su operación atómica, y pueden crear nuevas versiones con algunas comprobaciones propias)

Answer 2

Con v7.1.1, ClearCase admite confirmaciones atómicas. Podrá tratar un conjunto de archivos como una unidad y registrarlos o revertirlos según un criterio dado. Para obtener más información, para obtener más información, consulte https://publib.boulder.ibm.com/infocenter/cchelp/v7r1m0/index.jsp?topic=/com.ibm.rational.clearcase.relnotes.doc/topics/c_cc_relnotes_features.htm

Answer 3

Bloquea a todos los demás usuarios.

Haga una copia de seguridad de su servidor.

Haz tus compromisos.

Si algo va terriblemente mal, restaure el clearcase desde la copia de seguridad.

Answer 4

No he usado clearcase en años, así que aquí hay algunos pensamientos ingenuos y extraviados.

Mire hacia adelante y determine si los archivos no están sincronizados.

Bloquearía todos los archivos que estás a punto de registrar antes de registrarlos, y si no logras bloquear uno, abortar todo el lío, con un mensaje útil.

¿Puedes " eliminar " un check in? O revertir, ¿entonces HEAD mira una versión anterior? Defina su deshacer de un check in.

¿Puede hacer una sucursal temporal, registrar, luego fusionar / reagrupar (mi terminología se pierde aquí)? De esa manera tu retroceso es para matar la rama. Aunque recuerdo a compañeros de trabajo maldiciendo Clearcase debido a su ramificación.

En general, las acciones de puesta en cola son excelentes, pero use la cola para identificar posibles problemas antes de que ocurran. Además, define tus acciones y sus criterios de UNDO, de modo que si quieren hacer algo que no sea pseudo-atómico, puedes advertirles, " Esto podría causar problemas ''.