▷¿Cuáles son los conceptos básicos de clearcase que todo desarrollador debería conocer? ✔️ Foro Ayuda 【 2024 】

Este equipo de redactores ha pasado mucho tiempo buscando para darle respuesta a tu búsqueda, te ofrecemos la resolución por eso nuestro objetivo es serte de gran apoyo.

Solución:

Centro ¿conceptos?

VCS centralizado (replicado): ClearCase está a medio camino entre el mundo de VCS centralizado (uno o varios repositorios “centralizados” o VOBS – Version Object Bases – cada desarrollador debe acceder para confirmar) y el mundo de VCS distribuido.
Pero también admite un modo “replicado” que le permite replicar un repositorio en un sitio distante (MultiSite ClearCase), enviando deltas y administrando la propiedad. (Sin embargo, las tarifas de licencia adjuntas son bastante elevadas)
Este no es un verdadero modelo “descentralizado”, ya que no permite concurrente evoluciones: Las ramas se dominan en un VOB u otro; solo puede registrarse en el VOB maestro para las sucursales dominadas allí, aunque tiene acceso de solo lectura a cualquier sucursal en cualquier réplica.
almacenamiento de versión lineal: cada archivo y directorio tiene una historia lineal; no existe una relación directa entre ellos como el DAG VCS (Gráfico Acíclico Dirigido) donde el historial de un archivo está vinculado al de un directorio vinculado a una confirmación.
Eso significa
- cuando compara dos confirmaciones, debe comparar la lista de todos los archivos y directorios para encontrar el delta, ya que las confirmaciones no son atómicas en todos los archivos o directorios, lo que significa que no hay un nombre único para todos los cambios en todos los archivos que componen un delta lógico.
- Eso también significa un unir debe encontrar un común contribuyente base (no siempre lo mismo que un antepasado común) a través de la exploración de la historia (ver el siguiente punto).
  
  (Git está en el extremo opuesto de ese espectro, siendo tanto descentralizado como orientado a DAG:
  - si un nodo de su gráfico tiene el mismo “id” que un nodo de una confirmación diferente, no tiene que explorar más: se garantiza que todos los subgráficos son idénticos
  - la fusión de dos ramas es en realidad la fusión del contenido de dos nodos en un DAG: recursivo y muy rápido para encontrar un ancestro común)

texto alternativo http://publib.boulder.ibm.com/infocenter/cchelp/v7r0m0/topic/com.ibm.rational.clearcase.hlp.doc/cc_main/images/merg_base_contrib.gif

Fusión de 3 vías: para fusionar dos versiones, ClearCase debe encontrar un colaborador común en su historial lineal, que puede ser bastante largo para el árbol de versiones complejas (rama / sub-rama / sub-sub / rama, …), y la fusión básica de ClearCase El comando fusiona un archivo o directorio, pero no es recursivo. Solo afecta a un solo archivo, o un solo directorio sin sus archivos (ct findmerge es recursivo)
centrado en archivos (a diferencia de los otros VCS recientes más centrados en el repositorio): eso significa que la confirmación es archivo por archivo, no “conjunto de archivos modificados”: la transacción es a nivel de archivo. Una confirmación de varios archivos no es atómica.
(Casi todos los demás moderno La herramienta está “centrada en el repositorio”, con una transacción de confirmación atómica, pero los sistemas de primera generación como RCS, SCCS, CVS y la mayoría de los otros sistemas más antiguos no tienen esa característica).
ID gestionado: cada archivo y directorio tiene una identificación única, lo que significa que se pueden renombrar a voluntad: su historial no cambiará ya que la identificación permanece para el “elemento”. Además, un directorio detectará en su historial cualquier adición / supresión de archivo. Cuando se “elimina” un archivo (rmname), no lo sabe: solo se notifica al directorio y se crea una nueva versión en su historial, con una lista de subelementos sin incluir el archivo eliminado.

(Cree dos archivos con el mismo tamaño y contenido, obtendrán la misma identificación en Git, una clave SHA1, ¡y se almacenarán solo una vez en el repositorio de Git! No es así en ClearCase.
Además, si se crean dos archivos con la misma ruta y nombre en dos ramas diferentes, su ID es diferente significa que esos dos archivos nunca se fusionarán: se llaman “gemelos malvados“)

las sucursales son ciudadanos de primera clase: la mayoría de los VCS consideran que una rama y una etiqueta son lo mismo: un único punto en el historial desde el cual puede crecer un nuevo historial lineal (rama) o desde donde se adjunta una descripción (etiqueta).
No es así para ClearCase, donde una rama es una forma de hacer referencia a un número de versión. Cualquier número de versión comienza en 0 (solo se hace referencia en ClearCase) a 1, 2, 3, y así sucesivamente. Cada rama puede contener una nueva lista de números de versión (0, 1, 2, 3 nuevamente).
Esto es diferente de otros sistemas donde el número de versión es único y siempre está creciendo (como las revisiones en SVN), o simplemente es único (como las claves SHA1 en Git).
acceso a la ruta: para acceder a una determinada versión de un archivo / directorio, necesita conocer su ruta extendida (compuesta por ramas y versiones). Se llama “nombre de ruta extendido”: [email protected]@/main/subBranch/Version.

(Git se refiere a todo a través de id – basado en SHA1 -: versión [or commit], árbol [or version of a directory] y mancha [or version of a file, or rather of a content of a file]. Por lo tanto, es “accedido por id” o “referenciado por id”.
Para ClearCase, una identificación se refiere a un “elemento”: un directorio o un archivo, cualquiera que sea su versión).

cerradura pesimista y cerradura optimista: (pagos reservados o no reservados en ClearCase): incluso un bloqueo pesimista (pago reservado) no es realmente pesimista, ya que otros usuarios aún pueden retirar ese archivo (aunque en “modo sin reservas”): pueden cambiarlo pero tendrán que hacerlo espere a que el primer usuario confirme su archivo (registro) o cancele la solicitud. Luego fusionarán su versión de pago de ese mismo archivo.
(Nota: un pago “reservado” puede liberar su bloqueo y no ser reservado, ya sea por el propietario o el administrador)
ramificación barata: una rama no activa una copia de todos los archivos. En realidad, no desencadena nada: cualquier archivo que no se haya retirado permanecerá en su rama original. Solo los archivos modificados tendrán sus nuevas versiones almacenadas en la rama declarada.
almacenamiento de archivos planos: los VOB se almacenan en un formato propietario con archivos simples. Esta no es una base de datos con un lenguaje de consulta sencillo.
acceso al espacio de trabajo local o en red:
- el espacio de trabajo local se realiza mediante el pago en el disco duro (“actualización” de una vista instantánea).
- El espacio de trabajo de la red es a través de la vista dinámica, combinando archivos versionados y acceso a directorios a través de la red (sin copia local, acceso instantáneo) y archivos locales (los que están desprotegidos o los archivos privados). La combinación de archivos distantes (versionados) y locales (privados) permite que una vista dinámica parezca un disco duro clásico (mientras que en realidad cualquier archivo “escrito” se almacena en el almacenamiento de vista asociado).
almacenamiento centralizado para deportados: [view] El almacenamiento está ahí para guardar algunos datos y evitar alguna o cualquier comunicación con el referencial central.
un espacio de trabajo puede tener:
- un almacenamiento disperso: como el .svn subdirectorios por todo el lugar
- un almacenamiento centralizado: como el almacenamiento de vistas en ClearCase, contienen información sobre los archivos mostrados por la vista y ese almacenamiento es único para una vista.
- un almacenamiento deportado: el almacenamiento no es parte de la vista / espacio de trabajo en sí, pero puede ubicarse en otro lugar de la computadora o incluso fuera de la LAN / WAN

(Git no tiene “almacenamiento” per se. Su .git es en realidad todo el repositorio!)

orientado a metadatos: cualquier “valor-clave” puede adjuntarse a un archivo o directorio, pero ese par de datos no se registra en el historial: si el valor cambia, anula el valor anterior.

(lo que significa que el mecanismo es en realidad más débil que el sistema de “propiedades” de SVN, donde las propiedades pueden tener un historial;
Git en el otro extremo no está muy interesado en los metadatos)

protección basada en el sistema: el propietario y los derechos asociados con un archivo / directorio o repositorios se basan en la gestión de derechos del sistema subyacente. No hay una cuenta aplicativa en ClearCase, y el grupo de usuarios se basa directamente en el grupo existente de Windows o Unix (lo cual es bastante desafiante en un entorno heterogéneo, con clientes de Windows y un servidor VOB de Unix).

(SVN es más como una protección “basada en servidor”, donde el servidor Apache puede obtener un primer nivel de protección, pero debe completarse con ganchos para tener una gran cantidad de derechos.
Git no tiene administración de derechos directa y debe ser controlado por ganchos durante el empuje o extracción entre repositorios)

ganchos disponibles: cualquier acción de ClearCase puede ser el objetivo de un gancho, llamado disparador. Puede ser una operación previa o posterior.
CLI administrado: cleartool es la interfaz de línea de comandos desde la que se pueden realizar todas las acciones.

ClearCase es una bestia de usar. Lento, con errores y caro. Algunas cosas que he hecho para hacer frente al uso de CC son:

Siempre ponga buenos comentarios cuando se registre.
Utilice una especificación de configuración común y no la cambie con mucha frecuencia.
Nunca intente usar CC a través de una VPN o una conexión de red lenta.
Apague la carga de CC doctor en el inicio.
No mueva archivos a diferentes directorios.
Programe al menos 2 minutos por archivo para el registro.
Las vistas instantáneas son lentas, pero las vistas dinámicas son más lentas.
Adquiera el hábito de desarrollo de registrar temprano y con frecuencia porque los archivos reservados y las fusiones son dolorosos.
Haga que todos los desarrolladores revisen los archivos sin reserva de forma predeterminada.

Hemos estado usando CC durante poco más de quince años. Tiene muchas buenas características.

Todo nuestro desarrollo se realiza en sucursales; Creé un par hoy, para un par de cambios diferentes. Cuando me registré en la sucursal, pedí a un colega que revisara los cambios y luego volví a fusionarme con / main / LATEST, que es donde mi trabajo necesitaba ir. Si hubiera sido por una versión anterior en una rama, no habría sido más difícil.

Las fusiones de mis ramas temporales fueron completamente automáticas; nadie había cambiado los archivos en los que trabajaba mientras los revisaba. Aunque los pagos por defecto están reservados (bloqueados), siempre puede anular la reserva del pago más tarde o crear el pago sin reservas. Cuando los cambios toman varios días, la resincronización de mi rama temporal con la rama principal es fácil y generalmente automática. La herramienta mergetool está bien; El mayor problema para mí es que mi servidor está a 1800 millas aproximadamente de mi oficina (o casa), por lo que X sobre esa distancia es un poco lento (pero no intolerablemente). No he usado una herramienta de fusión mejor, pero puede que eso no diga mucho, ya que no he usado ninguna otra herramienta gráfica. mergetool.

Las vistas (vistas dinámicas) son rápidas en nuestra configuración. No he usado vistas instantáneas, pero no trabajo en Windows cuando puedo evitarlo (nuestro equipo usa vistas instantáneas en Windows; no tengo claro por qué). Tenemos sistemas de ramificación complejos, pero el desarrollo principal se realiza en / main / LATEST, y el trabajo de lanzamiento se realiza en una ramificación. Después de GA, el trabajo de mantenimiento se realiza en una rama específica de la versión y se fusiona con / main / LATEST (a través de cualquier versión intermedia).

CC necesita buenos administradores, los tenemos y tenemos la suerte de hacerlo.

CC no es trivial de usar, aunque en este momento, encuentro ‘git’ tan desalentador como CC para aquellos que no lo han usado. Pero los conceptos básicos son prácticamente los mismos: pago, cambio, registro, fusión, bifurcación, etc. Los directorios se pueden ramificar, con precaución, y ciertamente están controlados por versiones. Eso es invaluable.

No veo que la oficina cambie de CC en ningún momento.

Números de versión incrustados: ¿buenos o malos?

Escribí:

El mayor problema que tengo con CC es que no incrusta los números de versión en los archivos de origen, un problema que también tiene git, AFAICT. Puedo ver a medias por qué; Sin embargo, no estoy seguro de que me guste renunciar a esa capacidad de seguimiento. Entonces, sigo usando RCS (ni siquiera CVS) para la mayor parte de mi trabajo personal. Un día, puedo cambiar a git, pero será una sacudida y tomará mucho trabajo reorganizar los sistemas de lanzamiento configurados alrededor (SCCS y) RCS.

En respuesta, @VonC señala:

Siempre consideramos esa práctica como maligna (mezclar información de metadatos en datos), introduciendo “fusionar el infierno”. Consulte también Cómo obtener la versión del archivo Clearcase dentro de un archivo Java. Por supuesto, puede utilizar un activador para la sustitución de palabras clave RCS (Manual Clearcase: Ejemplo de activador de registro) siempre que utilice un administrador de combinación adecuado.

Hay varios temas expuestos en esta discusión y todos se mezclan. Mis puntos de vista rayan en lo arcaico, pero tienen un fundamento detrás de ellos, y me tomaré el tiempo para escribirlos (arruinado por la vida; puede que se necesiten varias ediciones para completar esto).

Fondo

Aprendí SCCS en 1984, aproximadamente cuando se lanzó RCS (1983, creo), pero SCCS estaba en mi máquina e Internet era incipiente en el mejor de los casos. Me mudé de SCCS a RCS a regañadientes a mediados de los 90 porque el formato de fecha de SCCS usa dos dígitos durante años y no estaba claro si SCCS se fijaría universalmente en el tiempo (lo era). En algunos aspectos, no me gusta RCS tanto como SCCS, pero tiene algunos puntos buenos. Comercialmente, mi empleador usó SCCS hasta mediados de 1995, pero comenzaron a cambiar a Atria ClearCase desde principios de 1994, abordando conjuntos de productos separados uno a la vez.

Experimente ClearCase con disparadores y fusionar el infierno

Nuestro proyecto migró más tarde, cuando ya había algo de experiencia con CC. En parte porque insistí en ello, incorporamos información de control de versiones en los archivos de origen a través de un activador de registro. Esto duró un tiempo, pero solo un tiempo, porque, como afirma VonC, conduce a la fusión del infierno. El problema es que si una versión con la etiqueta / main / branch1 / N se fusiona con / main / M de la versión base común / main / B, las versiones extraídas de los archivos contienen una sola línea que tiene ediciones en cada versión – un conflicto. Y ese conflicto debe resolverse manualmente, en lugar de manejarse automáticamente.

Ahora, SCCS tiene palabras clave de identificación. Las palabras clave de ID toman dos formatos, uno para los archivos que se están editando y otro para los archivos que no se están editando:

Edit         Non-Edit
%I%          9.13
%E%          06/03/09
%Z%          @(#)
%M%          s.stderr.c

Si intentó una combinación de 3 vías de las versiones editables de los archivos SCCS (con la notación% x%), entonces no habría conflictos en las líneas que contienen metadatos a menos que cambie los metadatos en esas líneas (por ejemplo, cambiando de US- estilo% D% fechas a fechas% E% estilo Reino Unido – SCCS no admite fechas de estilo ISO 2009-03-15 como estándar).

RCS también tiene un mecanismo de palabras clave, y las palabras clave también toman dos formatos, aunque uno es para archivos que aún no se han insertado en RCS y el otro es para aquellos que tienen:

Original       After insertion
$Revision$     $Revision: 9.13 $
$Date$         $Date: 2009/03/06 06:52:26 $
$RCSfile$      $RCSfile: stderr.c,v $

La diferencia está entre un ‘$’ después de la palabra clave y un ‘:’, espacio, texto, espacio y finalmente un ‘$’. No he fusionado lo suficiente con RCS para estar seguro de lo que hace con la información de palabras clave, pero observo que si tratara las notaciones expandidas y ‘contraídas’ como equivalentes (independientemente del contenido del material expandido), entonces la fusión podría tener lugar sin conflictos, dejando la notación contraída en la salida de la combinación, que se ampliaría adecuadamente cuando se recupere el archivo resultante después de la verificación.

El problema de ClearCase es la ausencia de un administrador de fusiones apropiado

Como indiqué en mi discusión sobre SCCS y RCS, si se realiza una combinación de 3 vías tratando las palabras clave en los formatos correctos (contratados o editables), entonces no hay conflicto de combinación.

El problema con CC (desde este punto de vista, claramente, los implementadores de CC no están de acuerdo) es que carece de un sistema para manejar palabras clave y, por lo tanto, también carece de un administrador de fusiones adecuado.

Si hubiera un sistema para manejar palabras clave y un administrador de fusiones apropiado, entonces:

El sistema incrustaría automáticamente los metadatos en archivos en los marcadores apropiados.
Al fusionarse, el sistema reconocería que las líneas con los marcadores de metadatos no entran en conflicto a menos que los marcadores cambien de manera diferente; ignoraría el contenido de los metadatos.

La desventaja de esto es que requiere una herramienta de diferencia especial que reconozca los marcadores de metadatos y los trate de manera especial, o requiere que los archivos alimentados a la herramienta de diferencia sean canonicalizados (los marcadores de metadatos se reducen a la forma neutral – $ Keyword $ o % K% en términos RCS y SCCS). Estoy seguro de que este pequeño trabajo adicional es la razón por la que no es compatible, algo que siempre he sentido que es miope en un sistema tan poderoso. No tengo ningún apego particular a las notaciones RCS o SCCS (las notaciones SCCS son más fáciles de manejar en algunos aspectos, pero son esencialmente equivalentes) y se podría usar cualquier notación equivalente.

Por qué sigo pensando que los metadatos del archivo son buenos

Me gusta tener los metadatos en el código fuente porque mi código fuente (a diferencia del código fuente de mi empleador) se distribuye fuera del ámbito del sistema de control del código fuente. Es decir, es principalmente de código abierto, lo pongo a disposición de todos y cada uno. Si alguien informa un problema en un archivo, especialmente en un archivo que ha modificado, creo que es útil saber desde dónde comenzó, y eso está representado por los metadatos originales en el archivo de origen.

Aquí, SCCS tiene una ventaja sobre RCS: las formas expandidas de las palabras clave de SCCS son indistinguibles del texto normal, mientras que las palabras clave de RCS continúan pareciendo palabras clave, por lo que si la otra persona ha importado el material a su propio repositorio de RCS, sus metadatos reemplazan mis metadatos, un problema que no ocurre con SCCS de la misma manera (la otra persona tiene que trabajar para sobrescribir los metadatos).

En consecuencia, incluso si alguien toma una parte de mi código fuente y lo modifica, por lo general hay suficientes etiquetas en él para identificar de dónde vino, en lugar de dejarme especular sobre en qué versión se basa. Y eso, a su vez, hace que sea más fácil ver qué partes del problema son de mi creación y qué partes de ellos.

Ahora, en la práctica, la forma en que funciona el código abierto, la gente no migra el código tanto como podría pensar. Tienden a apegarse bastante a la versión publicada, simplemente porque desviarse es demasiado caro cuando se hace el próximo lanzamiento oficial.

No estoy seguro de cómo se supone que debe determinar la versión base de un fragmento de código fuente que se originó a partir de su trabajo y ha sido revisado desde entonces. Sin embargo, encontrar la versión correcta parece clave para hacerlo, y si hay huellas digitales en el código, entonces puede ser más fácil.

Entonces, ese es un resumen moderado de por qué me gusta incrustar la información de la versión en los archivos de origen. Es en gran parte histórico: tanto SCCS como RCS lo hicieron, y me gustó el hecho de que lo hicieron. Puede ser una reliquia antigua, algo para despedirse en la era de DVCS. Pero eso todavía no me ha convencido del todo. Sin embargo, podría ser necesario un ensayo más para explicar los entresijos de mi mecanismo de gestión de versiones para ver por qué hago las cosas como las hago.

Un aspecto del razonamiento es que los archivos clave, como ‘stderr.c’ y ‘stderr.h’, son utilizados esencialmente por todos mis programas. Cuando publico un programa que lo usa, simplemente me aseguro de tener la versión más reciente, a menos que haya habido un cambio de interfaz que requiera una versión anterior. No he tenido ese problema desde hace un tiempo (hice un cambio de nombre sistemático en 2003; eso me causó algunos dolores de cabeza durante la transición, pero los scripts de Perl me permitieron implementar el cambio de nombre con bastante facilidad). No sé cuántos programas usan ese código; entre 100 y 200 sería una suposición justa. El conjunto de cambios de este año (la serie de la versión 9.x) sigue siendo algo especulativo; Finalmente no he decidido si me quedo con ellos. También son internos a la implementación y no afectan la interfaz externa, por lo que todavía no tengo que tomar una decisión. No estoy seguro de cómo manejar eso usando git. No quiero compilar el código de la biblioteca en una biblioteca que deba instalarse antes de que pueda compilar mi software; eso es demasiado oneroso para mis clientes. Por lo tanto, cada programa continuará distribuyéndose con una copia del código de la biblioteca (un tipo diferente de oneroso), pero solo el código de la biblioteca que necesita el programa, no toda la biblioteca. Y selecciono y elijo para cada programa qué funciones de biblioteca se utilizan. Entonces, no estaría exportando un subárbol completo; de hecho, la confirmación que cubrió los últimos cambios en el código de la biblioteca generalmente no está relacionada con la confirmación que cubrió los últimos cambios en el programa. Ni siquiera estoy seguro de si git debería usar un repositorio para la biblioteca y otro para los programas que lo usan, o un repositorio común más grande. Y no migraré a git hasta que entienda esto.

Está bien, basta de tonterías. Lo que tengo funciona para mí; no es necesariamente para todos. No impone exigencias extraordinarias al VCS, pero requiere metadatos de la versión incrustados en los archivos, y CC, Git y (creo) SVN tienen problemas con eso. Probablemente signifique que soy yo el que tiene problemas, problemas con el pasado perdido. Pero valoro lo que el pasado tiene que ofrecer. (Puedo salirme con la mía porque la mayor parte de mi código no está ramificado. No estoy seguro de cuánta diferencia haría la ramificación).

Aquí tienes las comentarios y puntuaciones

Al final de la web puedes encontrar las notas de otros sys admins, tú asimismo eres capaz insertar el tuyo si lo deseas.

¡Haz clic para puntuar esta entrada!

(Votos: 0 Promedio: 0)

Tags : Clearcase /

¿Cuáles son los conceptos básicos de clearcase que todo desarrollador debería conocer?