¿Cuáles son los conceptos básicos de clearcase que todo desarrollador debe conocer? [cerrado]

ClearCase es una bestia para usar. Lento, con buggy y caro. Algunas cosas que he hecho para lidiar con el uso de CC son:

1. Siempre ponga buenos comentarios cuando se registre.
2. Use una especificación de configuración común y no la cambie muy a menudo.
3. Nunca intente usar CC a través de una VPN o una conexión de red lenta.
4. Desactive la carga de CC doctor al iniciar.
5. No mueva archivos a diferentes directorios.
6. Programar al menos 2 min por archivo para checkin.
7. Las vistas de instantáneas son lentas, pero las vistas dinámicas son lentas.
8. Haga un hábito de desarrollo de verificar temprano y a menudo porque los archivos reservados y las fusiones son dolorosos.
9. Haga que todos los desarrolladores revisen los archivos sin reservas de forma predeterminada.

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

Todo nuestro desarrollo se realiza en ramas; he creado un par hoy, para un par de diferentes conjuntos de cambios. Cuando me registré en la rama, conseguí que un colega revisara los cambios, y luego me fusioné de nuevo en /main/LATEST, que es donde tenía que ir mi trabajo. Si hubiera sido por una versión anterior en una rama, no habría sido más difícil.

Las fusiones de mi las ramas temporales eran completamente automáticas; nadie había cambiado los archivos en los que trabajaba mientras los revisaba. Aunque de forma predeterminada las cajas están reservadas (bloqueadas), siempre puede dejar de reservar la caja más tarde o crear la caja 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. El mergetool está bien; el mayor problema para mí es que mi máquina servidor está a 1800 millas más o menos de mi oficina (o inicio), por lo que X sobre que distante es un poco lento (pero no intolerablemente así). No he usado una mejor mergetool, pero eso puede no decir mucho ya que no he usado ninguna otra mergetool gráfica.

Las vistas (vistas dinámicas) son rápidas en nuestra configuración. No he usado vistas de instantáneas, pero no trabajo en Windows cuando puedo ayudarlo (nuestro equipo usa vistas de 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 liberación es hecho en una rama. Después de GA, el trabajo de mantenimiento se realiza en una rama específica de la versión, y se fusiona hacia adelante a / main / LATEST (a través de cualquier versión intermedia).

CC necesita buenos administradores - los tenemos y somos afortunados al hacerlo.

CC no es trivial de usar, aunque por el momento, encuentro 'git' tan desalentador como CC es para aquellos que no lo han usado. Pero los conceptos básicos son los mismos: checkout, change, checkin, merge, branch, etc. Los directorios se pueden ramificar-con cautela - y ciertamente son versión controlada. Eso es invaluable.

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

Números de versión incrustados - ¿Bueno o Malo?

Escribí:

El mayor problema que tengo con CC es que no inserta números de versión en los archivos de origen, un problema que git también tiene, AFAICT. Puedo ver a medias por qué; no estoy seguro de que me guste renunciar a esa capacidad de seguimiento, sin embargo. Por lo tanto, todavía uso RCS (ni siquiera CVS) para la mayor parte de mi personal trabajo. Un día, puede que cambie a git, pero será una sacudida y tomará mucho trabajo rediseñar los sistemas de liberación configurados en torno a (SCCS y) RCS.

En respuesta, @VonC señala:

Siempre consideramos esa práctica como mala (mezclar información de metadatos en datos), introduciendo "merge hell". Vea también Cómo obtener la versión del archivo Clearcase dentro de un archivo Java. Por supuesto, puede usar un disparador para la sustitución de palabras clave RCS (Clearcase Manual: Checkin Trigger Example ) siempre que use un administrador de fusión apropiado.

Hay varios temas expuestos en esta discusión, y todos se mezclan. Mis puntos de vista rozan lo arcaico, pero tienen una lógica detrás de ellos, y voy a tomarme el tiempo para escribirlos (desordenado por la vida - puede tomar varias ediciones para completar esto).

Antecedentes

Aprendí SCCS en 1984, aproximadamente cuando RCS fue lanzado (creo que en 1983), pero SCCS estaba en mi máquina y el Internet estaba naciente 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 utiliza dos dígitos durante años y no estaba claro si SCCS se fijaría universalmente en el tiempo (lo fue). En algunos aspectos, no me gustan tanto los RCS como los SCCS, pero tiene algunos puntos positivos. Comercialmente, mi empleador utilizó SCCS hasta mediados de 1995, pero comenzaron a cambiar a Atria ClearCase desde principios de 1994, abordando conjuntos de productos separados uno a uno tiempo.

Experimento temprano de 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, incrustamos información de control de versiones en los archivos fuente a través de un disparador de check-in. Esto duró un tiempo - pero solo un tiempo-porque, como afirma VonC, conduce a fusionar el 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 tiene que resolverse manualmente, en lugar de manejarse automáticamente.

Ahora, SCCS tiene palabras clave ID. Las palabras clave 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 intenta una fusión de 3 vías de las versiones editables de archivos SCCS (con la notación %x%), entonces no habría conflictos en las líneas contiene metadatos a menos que haya cambiado los metadatos en esas líneas (por ejemplo, cambiando de fechas %D% al estilo estadounidense a fechas %E% al estilo británico-SCCS no admite fechas 2009-03-15 al estilo ISO 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 'following' después de la palabra clave y un':', espacio, texto, espacio y finalmente un '$'. No he hecho suficiente fusión con RCS para estar seguro de lo que hace con la información de palabras clave, pero me doy cuenta de que si se trata tanto las notaciones expandidas y 'contratadas' como equivalentes (independientemente del contenido del material expandido), entonces la fusión podría tener lugar sin conflicto, dejando la notación contratada en la salida de la fusión, que se expandiría adecuadamente cuando el archivo resultante se recupera después de checkin.

El problema de ClearCase es la ausencia de un gestor de fusión apropiado

Como he indicado en mi discusión de SCCS y RCS, si la fusión de 3 vías se realiza tratando las palabras clave en los formatos correctos (contratados o editables), entonces no hay conflicto de fusió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 el manejo de palabras clave, y por lo tanto también carece de un administrador de fusión apropiado.

Si había un sistema para el manejo de palabras clave y un adecuado merge manager, entonces:

• El sistema incrustaría automáticamente los metadatos en los archivos en los marcadores apropiados.
• Al combinar, 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 metadatos.

La desventaja de esto es que requiere una herramienta de diferencia especial que reconozca los marcadores de metadatos y los trate especialmente, o requiere que los archivos se alimenten a la la herramienta diferencia está canonizada (los marcadores de metadatos se reducen a la forma neutral - Keyword Keyword Keyword o %K% en términos RCS y SCCS). Estoy seguro de que este poco de trabajo extra es la razón por la que no es compatible, algo que siempre he sentido que era 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 cualquier notación equivalente podría ser utilizada.

Por qué todavía creo que los metadatos en el archivo es bueno

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 aegis del sistema de control de código fuente. Es decir, en su mayoría es de código abierto, lo pongo a disposición de todos y cada uno. Si alguien informa de un problema en un archivo, especialmente en un archivo que ha modificado, creo que es útil saber desde dónde comenzaron, y eso está representado por el original metadatos en el archivo de origen.

Aquí, SCCS tiene una ventaja sobre RCS: las formas expandidas de las palabras clave SCCS son indistinguibles del texto normal, mientras que las palabras clave RCS siguen pareciendo palabras clave, por lo que si la otra persona ha importado el material en su propio repositorio 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 un pedazo 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 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 fabricación, y qué partes son de su fabricación.

Ahora, en la práctica, la forma en que funciona el código abierto, las personas no migran el código tanto como se podría pensar. Tienden a quedarse con la versión lanzada bastante de cerca, 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 que ha sido revisado desde entonces. Encontrar la versión correcta, sin embargo, parece clave para hacer eso, y si hay huellas dactilares 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 fuente. Es en gran parte histórico-SCCS y RCS ambos lo hicieron, y me gustó el hecho de que lo hicieron. Puede ser una reliquia antigua, algo que se debe despedir en la era de las DVCS. Pero aún no estoy totalmente convencido por eso. Sin embargo, podría tomar aún más de un ensayo para explicar los entresijos de mi mecanismo de gestión de liberación para ver por qué hago las cosas como lo hago.

Un aspecto del razonamiento es que los archivos clave, como 'stderr.c ' y ' stderr.h', son utilizados por esencialmente todos mis programas. Cuando libero un programa que lo utiliza, simplemente me aseguro de que tengo la versión más reciente-a menos que haya habido un cambio de interfaz que requiere una versión posterior. No he tenido ese problema desde hace un tiempo (hice un cambio de nombre sistemático en 2003; eso causó algunos dolores de cabeza transicionales, pero los scripts de Perl me permitieron implementar el cambio de nombre con bastante facilidad). No se cuántos programas usan ese código-en algún lugar entre 100 y 200 sería una conjetura justa. El conjunto de cambios de este año (la versión 9.x series) son todavía algo especulativo; no he decidido finalmente si conservarlos. También son internas a la implementación y no afectan a la interfaz externa, por lo que no tengo que decidirme todavía. No estoy seguro de cómo manejar eso usando git. No quiero construir el código de la biblioteca en una biblioteca que debe instalarse antes de que pueda construir mi software, eso es demasiado oneroso para mis clientes. Por lo tanto, cada programa continuará siendo distribuido con una copia del código de la biblioteca (un tipo diferente de oneroso), pero solo el código de la biblioteca que el programa necesita, no toda la biblioteca. Y elijo y elijo para cada programa qué funciones de biblioteca se utilizan. Por lo tanto, no estaría exportando un sub-árbol completo; de hecho, el commit que cubrió los últimos cambios en el código de la biblioteca normalmente no está relacionado con el commit 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 repositorio. Y no migraré a Git hasta que no entienda esto.

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

Eric's Source Control HOWTO es una gran guía independiente de las herramientas.

Trabajé con clearcase durante la mayor parte de 6 años y generalmente lo encontré tolerable. Tiene una cierta curva de aprendizaje, pero una vez que te acostumbras a las peculiaridades, puedes trabajar sin problemas con él. Un administrador CC muy competente que sabe lo que está haciendo es esencial para cualquier cosa menos configuraciones triviales. A menos que tengas uno, la gente se va a topar con problemas y muy pronto se hablará del problema del "ClearCase". Entonces la gerencia tendrá que intervenir cambiando a otra cosa que solo causa una pérdida de tiempo para todos los involucrados. CC no es un mal producto, solo que a veces se entiende mal.

Aquí hay algunos conceptos que encontré importantes, algunos de estos no están orientados exclusivamente a CC -

• Un check-out es diferente a la noción normal de CVS de un check-out. Cuando usted echa un vistazo a bloquear el archivo hasta que se registra en él.
• No hay problema con mover archivos. de hecho, esto funciona perfectamente.
• Los árboles de versiones son esenciales para entender lo que ha estado sucediendo a un archivo. Pueden ser bastante desordenados para los archivos activos, pero cuando te acostumbras a verlos se convierte en una herramienta muy útil y una que carece de otras herramientas de control de código fuente como SVN (hasta cierto punto).
• No utilice vistas dinámicas bajo ninguna circunstancia. no vale la pena.
• antes de hacer una nueva rama, flujo o proyecto, aconseje a su administrador para asegurarse de que lo que crea es realmente lo que le servirá mejor. Al iniciar un nuevo code-base, asegúrese de obtener el diseño de flujos y proyectos desde el principio planificando con anticipación. cambiarlo más tarde es un verdadero dolor de cabeza si es posible.
• Ajuste los privilegios de los usuarios y configure disparadores para eventos comunes para evitar errores comunes o aplicar políticas. El servidor es muy configurable y la mayoría de los problemas que se encuentran probablemente hay una solución razonable.
• educar a los desarrolladores sobre cualquier cosa, desde conceptos básicos hasta operaciones avanzadas. Un usuario avanzado que puede encontrar lo que el problema está utilizando cleartool reduce la carga en el administrador.
• No dejes corrientes y vistas colgantes. Cuando un desarrollador abandona el proyecto, pídale a alguien que elimine todas las vistas que tenía en su máquina y elimine todas sus transmisiones privadas. No mantener su servidor limpio resultará en... es sucio y con el tiempo, lento. Cuando haces un "find all checkouts" en todas las transmisiones y vistas, no deberías ver los archivos que han sido extraídos por personas que ya no existir.
• Ordene una política de "siempre rebase antes de entregar" para las ramas secundarias para evitar que las personas "rompan el flujo de integración" cuando entreguen código que entre en conflicto con los cambios recientes.
• Integración continua - no dejes que el flujo de integración se estanque mientras cada desarrollador o equipo trabaja en su propia rama. Mandate una vez cada X vez todo el mundo tiene que al menos rebase a la línea de base de integración más reciente si no es para entregar sus cambios estables. Esto es de hecho muy difícil de hacer, especialmente con grandes proyectos, pero la otra alternativa es "infierno de integración", donde al final del mes nadie hace nada durante 3 días, mientras que un pobre cabrón intenta hacer que todos los cambios encajen

¡Cómo usar git encima de ClearCase!

• Git Backstage, Under the Covers and on the Down Low
• ClearCase Globalmente, Git Localmente
• Un Clearcase para Git , git-cc bridge

En mi opinión, la ramificación y la fusión son los conceptos más importantes en cualquier sistema de control de código fuente (junto al versionado en sí, por supuesto).

Una vez que entiendas cómo se hace (y Clearcase lo hace muy bien, hasta el punto en que hacemos incluso pequeños cambios como rama y re-fusionamos, algo que nunca habría hecho con RCS o CVS), encontrarás que tu vida se hace mucho más fácil.

De alguna manera fuera de tema, pero-no conozco casi ningún desarrollador que esté contento con ClearCase. Me dijeron que debería tener características sofisticadas, pero como usuario de svn y git no puedo pensar en algo que extrañe en git o subversion. Así que eso es algo que uno debe saber sobre ClearCase-la mayoría de los desarrolladores están muy contentos de trabajar con algo simple como subversion o git (sí, incluso git es más fácil de entender), e incluso después de que supe cómo completar las tareas más simples en ClearCase, tuve la constante sentir que ClearCase trabaja en mi contra, no conmigo.

He trabajado en varios proyectos medianos y grandes con éxito utilizando Clearcase y SVN. Ambas son excelentes herramientas, pero el equipo que las usa necesita procesos documentados. Cree un proceso que describa cómo utilizará el sistema de control de versiones.

1) busque o cree un documento de prácticas recomendadas para su Sistema de Control de Versiones. Aquí hay uno para subversion, adáptalo a tu proceso Clearcase. Todos los desarrolladores deben adherirse al mismo plan de juego.

Básicamente decidir si vas a 'siempre ramificar' o 'nunca ramificar'.

Nunca Branch Scheme:

• El esquema never branch es lo que SourceSafe usa cuando los archivos están bloqueados durante el proceso de pago y están disponibles durante el proceso de registro. Este esquema y está bien para pequeños (1 o 2 desarrolladores) proyectos de equipo.

Siempre Branch Scheme:

• El esquema always branch significa que los desarrolladores crean ramas para cada corrección de errores o adición de características. Este esquema es necesario para proyectos más grandes, los proyectos que tienen un lead (buildmeister) que gestiona los cambios que se permiten en /main/LATEST en Clearcase o /trunk en SVN.
• El esquema always branch significa que puedes checkear a menudo sin miedo a romper la compilación. Su única oportunidad de romper la compilación es solo después de que su corrección de error o característica esté completa y la combine con /main/LATEST.

'Branch when needed' es un compromiso y puede funcionar mejor para muchos proyectos.

2) Con Clearcase (y Subversion) debe aprende a fusionar merging fusionar es tu amigo. Aprenda a usar las capacidades de fusión de Clearcase o use una herramienta como Beyond Compare o emacs-diff. Si su proyecto está bien modularizado (muchos pequeños archivos desacoplados), se beneficiará con menos (o ningún) conflicto durante la fusión.

3) Disfruta.

Si está utilizando ClearCase, asegúrese de usar la UCM que viene con ella y los componentes compuestos.

Hace que toda tu ramificación/fusión sea fácil. Estoy hablando de las principales ramas de re-org que se ejecutan durante 6 meses que implican decenas de miles de cambios incluyen el cambio de nombre de directorios, el cambio de nombre de archivos, etc. que resuelven automáticamente el 99.9% de los deltas.

Además, solo usamos vistas instantáneas, no vistas dinámicas. Nuestras vistas de instantáneas se cargan más rápido de lo que puede arrastrar y soltar (Windows) el mismo árbol de fuentes de una unidad de red.

La única queja que tengo sobre UCM es que la historia no puede abarcar componentes. Si divide un componente en varios componentes nuevos, cada componente nuevo comienza en / main / 0.

Cómo implementar las herramientas de control de versiones en su proyecto depende del tamaño y el alcance del proyecto y de la experiencia anterior del equipo. ClearCase es una herramienta fantástica para proyectos más grandes entre los desarrolladores y el tamaño del proyecto. La gestión de la rama es una de las perspectivas muy importantes mientras se utiliza la herramienta de control de versiones. sin ramificar y fusionar, es una caminata fácil durante el ciclo de vida de su proyecto. Pero usted no puede permanecer lejos con la fusión de por qué porque es le permite bloquear y fantástico desarrollo paralelo.

Hay un comando muy útil cleardescribe que es útil muchas veces. Se puede utilizar para obtener los detalles de las etiquetas y ramas. La sintaxis es:

cleardescribe lbtype:<LABELNAME>@\<VOB-NAME>
cleardescribe brtype:<BRANCHNAME>@\<VOB-NAME>

Específicamente, esto le permite saber que la etiqueta se aplicó en qué rama y qué rama es la rama padre a una rama en cuestión.