¿Cuáles son los conceptos básicos claros que todo desarrollador debe saber? [cerrado]

StackOverflow https://stackoverflow.com/questions/645008

  •  22-07-2019
  •  | 
  •  

Pregunta

¿Cuáles son los conceptos centrales del sistema de control de versiones Clearcase que todo desarrollador debe conocer?

¿Fue útil?

Solución

Core conceptos?

  • VCS centralizado (replicado) : ClearCase está a medio camino entre el mundo VCS centralizado (uno o varios repositorios centralizados o VOBS - Bases de objetos de versión - cada desarrollador debe acceder a la confirmación ) y el mundo VCS distribuido.
    Pero también es compatible con un "replicado" modo que le permite replicar un repositorio en un sitio distante (MultiSite ClearCase), enviar deltas y administrar la propiedad. (las tarifas de licencia adjuntas son bastante elevadas)

    Esto no es un verdadero "descentralizado" modelo, ya que no permite evoluciones paralelas concurrentes : las ramas se dominan en un VOB u otro; solo puede registrarse en el VOB maestro para las ramas dominadas allí, aunque solo tiene acceso de lectura a cualquier rama en cualquier réplica.

  • almacenamiento de versión lineal : cada archivo y directorio tiene un historial lineal; no existe una relación directa entre ellos como el DAG VCS ( Gráfico acíclico dirigido ) donde la historia de un el 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 entre archivos o directorios, lo que significa que no hay un nombre único para todos los cambios en todos los archivos que hacer un delta lógico.

    • Eso también significa un merge debe encontrar un 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, ya que está descentralizado y orientado a DAG:

      • si un nodo de su gráfico tiene el mismo '' id '' como un nodo de una confirmación diferente, no tiene que explorar más: se garantiza que todos los sub-gráficos sean 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 antepasado 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 contribuyente basado en común en su historial lineal, que puede ser bastante largo para el árbol de versiones complejas (branch / sub-branch / sub-sub / branch, .. .), y el comando ClearCase merge básico combina un archivo o directorio, Pero no es recursivo. Solo afecta a un archivo singe, o un solo directorio sin sus archivos ( ct findmerge es recursivo)

  • centrado en archivos (a diferencia del otro VCS más centrado en el repositorio reciente): eso significa que el commit 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 todas las otras herramientas modernas están centradas en el repositorio, con una transacción de confirmación atómica, pero sistemas de primera generación como RCS, SCCS, CVS y mLa mayoría de los otros sistemas antiguos no tienen esa característica.

  • administrado por identificación : cada archivo y directorio tiene una identificación única, lo que significa que pueden renombrarse 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 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 " twins malvados ")

  • las ramas son ciudadanos de primera clase : la mayoría de los VCS consideran una rama y una etiqueta como lo mismo: un único punto en la historia desde el cual puede crecer una nueva historia 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 (recién referenciado 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 es único (como las teclas SHA1 en Git).

  • ruta de acceso : para acceder a una determinada versión de un archivo / directorio, debe conocer su ruta extendida (compuesta de ramas y versiones). Se llama " nombre de ruta extendido " ;: myFile@@/main/subBranch/Version.

(Git se refiere a todo a través de id - basado en SHA1 -: versión [o commit], árbol [o versión de un directorio] y blob [o versión de un archivo, o más bien de un contenido de un archivo]. Por lo tanto, es "id-access" o "id-referenced".
Para ClearCase, una identificación se refiere a un " elemento " ;: un directorio o un archivo, cualquiera que sea su versión.

  • bloqueo pesimista y bloqueo optimista : (pagos reservados o no reservados en ClearCase): incluso un bloqueo pesimista (pago reservado) no es un pesimista verdadero, ya que otros usuarios aún pueden pagar ese archivo (aunque en "modo sin reservas"): pueden cambiarlo pero tendrán que esperar a que el primer usuario confirme su archivo (registro) o cancele la solicitud. Luego fusionarán su versión de pago del mismo archivo.
    (Nota: un pago " reservado " puede liberar su bloqueo y quedar sin reservas, 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 esté prestado 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 fácil.

  • acceso al espacio de trabajo local o de red :

    • el espacio de trabajo local se realiza mediante el pago en el disco duro (" actualización " de una vista de 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 aparezca como un disco duro clásico (mientras que en realidad cualquier archivo "escrito" se almacena en el almacenamiento de vista asociado).

Otros consejos

ClearCase es una bestia para usar. Lento, con errores 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 sobre una VPN o una conexión de red lenta.
  4. Apague la carga de CC doctor al inicio.
  5. No mueva archivos a diferentes directorios.
  6. Programe al menos 2 minutos por archivo para el registro.
  7. Las vistas instantáneas son lentas, pero las vistas dinámicas son más lentas.
  8. Adquiera el hábito de desarrollo de registrarse temprano y con frecuencia 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 por poco más de quince años. Tiene muchas buenas características.

Todo nuestro desarrollo se realiza en sucursales; Creé una pareja hoy, para un par de diferentes conjuntos de cambios. Cuando me registré en la sucursal, conseguí que un colega revisara los cambios, y luego volví a fusionarme con / 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 mis ramas temporales fueron completamente automáticas; nadie había cambiado los archivos en los que trabajé mientras los revisé. Aunque por defecto los pagos están reservados (bloqueados), siempre puede cancelar la reserva más tarde o crear el pago sin reserva. 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 de combinación está bien; El mayor problema para mí es que mi máquina servidor está a 1800 millas más o menos de mi oficina (u hogar), por lo que X a esa distancia es un poco lento (pero no intolerablemente). No he usado una herramienta Mergetool mejor, pero eso puede no decir mucho ya que no he usado ninguna otra herramienta 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 evitarlo (nuestro equipo usa vistas de instantáneas en Windows; no estoy 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 sucursal. 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 lo es para aquellos que no lo han usado. Pero los conceptos básicos son muy parecidos: pago, cambio, registro, fusión, ramificación, etc. Los directorios se pueden bifurcar, con precaución, y ciertamente se controlan las versiones. Eso es invaluable.

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

Números de versión incorporada: ¿bueno o malo?

Escribí:

  

El mayor problema que tengo con CC es que no incrusta números de versión en los archivos fuente, un problema que también tiene git, AFAICT. A medias puedo ver por qué; Sin embargo, no estoy seguro de que me guste renunciar a esa rastreabilidad. Entonces, todavía uso RCS (ni siquiera CVS) para la mayoría 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 de (SCCS y) RCS.

En respuesta, @VonC señala:

  

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

Hay varios problemas expuestos en esta discusión, y todos se mezclan. Mis puntos de vista rayan en lo arcaico, pero tengo una justificación detrás de ellos, y me tomaré el tiempo para escribirlos (desordenados por la vida, puede tomar varias ediciones para completar esto).

Fondo

Aprendí SCCS en 1984, sobre el momento en que 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 de mala gana en elmediados de los 90 porque el formato de fecha SCCS usa dígitos dobles durante años y no estaba claro si SCCS se fijaría universalmente en el tiempo (lo era). En algunos aspectos, no me gusta tanto RCS como SCCS, pero tiene algunos puntos positivos. 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.

Experimento ClearCase temprano con disparadores, y fusionar el infierno

Nuestro proyecto migró más tarde, cuando ya había cierta experiencia con CC. En parte porque insistí en ello, incorporamos información de control de versiones en los archivos fuente a través de un activador de registro. Esto duró un tiempo, pero solo un tiempo, porque, como dice VonC, lleva 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 debe resolverse manualmente, en lugar de manejarse automáticamente.

Ahora, SCCS tiene palabras clave de identificación. Las palabras clave de ID tienen 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á conflictos en las líneas que contienen metadatos a menos que cambie los metadatos en esas líneas (por ejemplo, cambiando desde fechas% D% de estilo estadounidense hasta fechas% E% de estilo británico: 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 tienen 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 es 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 trata tanto las anotaciones expandidas como las 'contratadas' como equivalentes (independientemente del contenido del material expandido), 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 se recupere el archivo resultante después del registro.

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

Como indiqué en mi discusión sobre 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 manejar palabras clave y, por lo tanto, también carece de un administrador de fusión apropiado.

Si hubiera un sistema para manejar palabras clave y un administrador de fusión apropiado, entonces:

  • El sistema incrustará automáticamente los metadatos en archivos en los marcadores apropiados.
  • Al fusionar, 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 reconoce los marcadores de metadatos y los trata especialmente, o requiere que los archivos alimentados a la herramienta de diferencia estén canonicalizados (los marcadores de metadatos se reducen a la forma neutral - $ Palabra clave $ o% K% en términos de 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 era miope en un sistema tan poderoso. No tengo ningún apego particular a las anotaciones RCS o SCCS: las anotaciones SCCS son más fáciles de manejar en algunos aspectos, pero son esencialmente equivalentes, y podría usarse cualquier notación equivalente.

Por qué sigo pensando que los metadatos en el archivo son buenos

Me gusta tener los metadatos en el snuestro código fuente porque mi código fuente (a diferencia del código fuente de mi empleador) se distribuye fuera del aegis de la fuente sistema de control de código 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 fuente.

Aquí, SCCS tiene una ventaja sobre RCS: las formas ampliadas de las palabras clave de SCCS no se pueden distinguir del texto normal, mientras que las palabras clave de RCS continúan pareciéndose a palabras clave, por lo que si la otra persona ha importado el material a su propio repositorio de RCS, sus metadatos reemplazan a mis metadatos, un problema que no ocurre con SCCS de la misma manera (la otra persona tiene que hacer un trabajo para sobrescribir los metadatos).

En consecuencia, incluso si alguien toma una parte de mi código fuente y lo modifica, generalmente hay suficientes etiquetas 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 creación y qué partes son de su creación.

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 ajustarse bastante a la versión lanzada, simplemente porque desviarse es demasiado costoso cuando se realiza el próximo lanzamiento oficial.

No estoy seguro de cómo se supone que debe determinar la versión base de un código fuente que se originó en su trabajo y que 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 fuente. 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 todavía no estoy totalmente convencido por eso. Sin embargo, podría tomar aún más ensayo explicar los entresijos de mi mecanismo de administración de versiones para ver por qué hago las cosas como lo hago.

Un aspecto del razonamiento es que los archivos de claves, como 'stderr.c' y 'stderr.h', son utilizados esencialmente por todos mis programas. Cuando lanzo un programa que lo usa, simplemente me aseguro de tener la versión más reciente, a menos que haya un cambio de interfaz que requiera una versión posterior. No he tenido ese problema por un tiempo (hice un cambio de nombre sistemático en 2003; eso causó algunos dolores de cabeza de 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; en algún lugar 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 mantenerlos. También son internos a la implementación y no afectan la interfaz externa, por lo que todavía no tengo que decidirme. No estoy seguro de cómo manejar eso usando git. No quiero construir el código de la biblioteca en una biblioteca que deba instalarse antes de que pueda construir 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 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, la confirmación que cubrió los últimos cambios en el código de la biblioteca generalmente no tiene ninguna relación 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

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

Trabajé con clearcase durante la mayor parte de 6 años y, en general, lo encontré tolerable. Tiene una cierta curva de aprendizaje, pero una vez que te acostumbras a las peculiaridades, puedes trabajar sin problemas con ella. Un administrador de CC muy competente que sepa lo que está haciendo es esencial para cualquier cosa que no sean configuraciones triviales. A menos que tenga uno, las personas se encontrarán con problemas y pronto se hablará sobre el " ClearCase " problema. Luego, la gerencia tendrá que intervenir cambiando a otra cosa que solo cause pérdida de tiempo para todos los involucrados. CC no es un mal producto, a veces es poco conocido.

Aquí hay algunos conceptos que me parecieron importantes, algunos de ellos no están orientados únicamente a CC -

  • Un check-out es diferente a la noción regular de CVS-like de un check-out. Cuando salga, bloqueará el archivo hasta que lo registre.
  • No hay problema con mover archivos. De hecho, esto funciona a la perfección.
  • Los árboles de versiones son esenciales para comprender lo que le ha estado sucediendo a un archivo. Pueden volverse bastante desordenados para los archivos activos, pero cuando se acostumbra a verlos, se convierte en una herramienta muy útil y que carece de otras herramientas de control de origen como SVN (en cierta medida).
  • No use vistas dinámicas bajo ninguna circunstancia. no vale la pena.
  • antes de crear una nueva sucursal, transmisión o proyecto, avise a su administrador para asegurarse de que lo que cree es realmente lo que le servirá mejor. Al comenzar una nueva base de código, asegúrese de obtener las secuencias y el diseño de los proyectos desde el principio planificando con anticipación. cambiarlo más tarde es un verdadero dolor de cabeza si es posible.
  • Ajusta los privilegios de los usuarios y configura activadores para eventos comunes para evitar errores comunes o aplicar políticas. El servidor es muy configurable y la mayoría de los problemas que encuentre probablemente sea una solución razonable.
  • educar a los desarrolladores sobre cualquier cosa, desde conceptos básicos hasta operaciones avanzadas. Un usuario avanzado que puede encontrar cuál es el problema que está usando Cleartool reduce la carga en el administrador.
  • No deje secuencias y vistas colgantes. Cuando un desarrollador abandone el proyecto, haga que alguien elimine todas las vistas que tenía en su máquina y elimine todas sus transmisiones privadas. No mantener el servidor limpio dará como resultado ... que esté sucio y, con el tiempo, lento. Cuando haces un " encuentra todos los pagos " en todas las transmisiones y vistas, no debería ver los archivos desprotegidos por personas que ya no existen.
  • Ordene un " siempre rebase antes de entregar " política de sucursales secundarias para evitar que las personas "interrumpan el flujo de integración" al entregar código que entra en conflicto con los cambios recientes.
  • Integración continua : no permita que el flujo de integración se estanque mientras cada desarrollador o equipo trabaja en su propia rama. Ordene una vez cada X cada vez que todos tengan que cambiar al menos a la línea de base de integración más reciente si no es para entregar sus cambios estables. De hecho, esto es muy difícil de hacer, especialmente con grandes proyectos, pero la otra alternativa es el "infierno de integración". donde a fin de mes nadie hace nada durante 3 días mientras un pobre pobre intenta hacer que todos los cambios encajen juntos

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

Una vez que comprenda cómo se hace (y Clearcase lo hace muy bien, hasta el punto en que realizamos incluso pequeños cambios como una ramificación y una nueva fusión, no es algo que hubiera hecho con RCS o CVS), usted encuentra que tu vida se hace mucho más fácil.

De alguna manera fuera de tema, pero no conozco a 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ño en git o subversion. Eso es algo que uno debería saber sobre ClearCase: la mayoría de los desarrolladores están realmente felices de trabajar con algo simple como subversión o git (sí, incluso git es más fácil de entender), e incluso después de saber cómo completar las tareas más simples en ClearCase, tuve el sentimiento constante de ClearCase funciona en mi contra, no conmigo.

He trabajado en varios proyectos medianos a grandes con éxito usando 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) encuentre o cree un documento de mejores prácticas para su Sistema de control de versiones. Aquí hay una para subversión , adapte a su proceso de Clearcase. Todos los desarrolladores deben cumplir con el mismo plan de juego.

Básicamente decida si va a 'siempre bifurcar' o 'nunca bifurcar'.

Nunca esquema de ramificación:

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

Esquema de rama siempre:

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

'Sucursal cuando sea necesario' es un compromiso y puede funcionar mejor para muchos proyectos.

2) Con Clearcase (y Subversion) debes aprender a fusionar: 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 archivos pequeños desacoplados), se beneficiará con menos (o ningún) conflicto durante la fusión.

3) Disfruta.

Si está usando ClearCase, asegúrese de usar el UCM que viene con él y los componentes compuestos.

Hace que todas tus ramificaciones / fusiones sean fáciles. Me refiero a las principales ramas de reorganización que se ejecutan durante 6 meses y que implican decenas de miles de cambios, incluidos 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 SnapShot, 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 origen desde una unidad de red.

La única queja que tengo sobre UCM es que el historial no puede abarcar componentes. Si divide un componente en múltiples componentes nuevos, cada nuevo componente comienza en / main / 0.

Cómo implementar las herramientas de control de versiones en su proyecto depende del tamaño y alcance de su proyecto y de la experiencia previa del equipo. ClearCase es una herramienta fantástica para proyectos de mayor envergadura de desarrolladores y tamaño del proyecto. Administrar la sucursal es una de las perspectivas más importantes al usar la herramienta de control de versiones. sin bifurcarse ni fusionarse es una caminata fácil durante el ciclo de vida de su proyecto. Pero no puede mantenerse alejado de la fusión porque le permite bloquear y un fantástico desarrollo paralelo.

Hay un comando muy útil cleardescribe que es útil muchas veces. Se puede usar para obtener los detalles de 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 principal de una rama en cuestión.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top