¿Cómo conectar git a ClearCase?

8 minutos de lectura

he usado recientemente git svn y lo disfruté mucho. Ahora estoy comenzando un nuevo proyecto en un cliente diferente. En ese sitio, el SCM elegido es ClearCase. No he encontrado un equivalente horneado de git svn para ClearCase. ¿Hay alguien que haya intentado usar git localmente como interfaz para ClearCase usando algunos trucos, configuración o secuencias de comandos con algún grado de éxito? Si es así, ¿puede explicar el método utilizado?

  • En mi humilde opinión, usar un puente empeora las cosas. ClearCase puede servir como un sistema de archivos tonto sobre el que puede usar git nativo completo; vea mi respuesta a continuación para obtener detalles del método que usamos.

    –Matt Curtis

    26 de febrero de 2010 a las 22:35

¿Como conectar git a ClearCase
matt curtis

Este es un método que evita los secuestros, que nuestro equipo usó este método con bastante éxito durante más de un año, hasta que retiramos ClearCase para Subversion (según la política de la empresa, aunque es un paso atrás para nuestro equipo: básicamente estábamos usando ClearCase como un tonto sistema de archivos, y funciona virtualmente de forma nativa en git, pero ahora estamos usando el puente git-svn que no es tan bueno como el git nativo).

Usamos dos directorios, uno para la instantánea de ClearCase y el repositorio maestro de git, que compartimos con todo el equipo y nunca editamos archivos, y otro para nuestro directorio de “trabajo”.

La preparación en la vista de instantánea de ClearCase es:

% git init
% git add **/*.cxx **/*.h **/Makefile (and so on)
% git commit -m "initial"

Luego clona en tu directorio de trabajo:

% mkdir ~/work
% git clone /path/to/repo

Trabaja en el directorio de trabajo, en una rama:

% git checkout -b feature
% ...edit/compile...
% git add -u
% git commit

Asegúrese de que la instantánea de ClearCase esté actualizada con prístino (que siempre lo fue para nosotros, porque lo compartimos entre el equipo y todos usamos git).

Luego fusione la rama en el maestro cambiándola de base, para evitar una confirmación de fusión automática:

% git checkout master
% git pull
% git checkout feature
% git rebase master
% git checkout master
% git merge feature
% git branch -d feature

% git diff --name-status origin/master

Prepare la vista de ClearCase extrayendo/mkelem/rmname cualquier archivo modificado/nuevo/eliminado, en función de la salida de git diff --name-status. Usamos un guión hecho a mano para hacer esto. No olvide revisar los directorios que tienen archivos agregados o eliminados:

Luego, retroceda las cosas de git y verifique con ClearCase:

% git push
% cd /path/to/repo
% git reset --hard
% cleartool ci `cleartool lsco -r -short -me`

Parecen muchos comandos, pero esto incluye la configuración y su flujo de trabajo diario no usa muchos comandos. Puede crear una secuencia de comandos de manera trivial en torno al paso de retroceder a ClearCase y descubrir/mostrar a su equipo todas las cosas geniales adicionales de git gradualmente a medida que todos se acostumbran al flujo de trabajo básico.

La verdadera belleza de este sistema es que, después de un tiempo, cuando todos son competentes con git, puedes deshacerte trivialmente de ClearCase y todo el trabajo de mono individual asociado y honorarios. Tal vez darle al chico de ClearCase de la compañía unas vacaciones muy necesarias y un poco de capacitación con los ahorros. (Lamentablemente, en mi empresa, todo el material de git era skunkworks, y nos mudamos a Subversion, ¡hacia adelante desde ClearCase pero hacia atrás desde git!)

I fuertemente te recomiendo que uses el pristine guión de ClearCase globalmente, Git localmente, que se ejecuta en la vista de instantánea de ClearCase y garantiza que git y git estén sincronizados. Configuramos esto como un trabajo cron que se ejecutaba dos veces al día, y también lo ejecutamos manualmente cada vez que estábamos a punto de retroceder a git. Desafortunadamente, el enlace a la publicación del blog ya no es válido. Sin embargo, el script todavía está disponible en Github.

  • Otra ventaja de este sistema es que algunos miembros del equipo pueden seguir usando ClearCase si así lo desean. Es un poco más complicado mientras eso sucede, ya que los usuarios de git necesitarán mantener las cosas sincronizadas cuando un usuario que no sea de git se registre. Eventualmente, los reticentes verán las ventajas que tienen los usuarios de git, y este problema desaparecerá. !

    –Matt Curtis

    26 de febrero de 2010 a las 22:37

  • Además, nuestro script push-back-to-ClearCase generó un comentario para ClearCase desde el registro de cambios de git desde origin/master, que usó con “cleartool co -c” y así sucesivamente, por lo que nuestro compromiso de cleartool no necesitaba un comentar en absoluto!

    –Matt Curtis

    26 de febrero de 2010 a las 22:40

  • Interesante técnica, +1. Como el “chico ClearCase” en mi tienda, me vendrían bien las vacaciones;) Pero también soy el chico SVN. Y Git Guy. Y un poco de Perforce y CM Synergy… Entonces no tengo vacaciones.

    – VoC

    26 de febrero de 2010 a las 23:52

  • Parte de esto fue accidental, porque (POR FAVOR, no preguntes) todos trabajamos en una vista estática CC compartida. ¡Puaj! Inicialmente, nuestra solución git era solo una forma de administrar nuestros propios directorios de trabajo privados, pero en general funcionó bastante bien porque el directorio compartido nos dio un lugar natural para nuestro repositorio git “maestro”, y también un lugar central único para hacer seguro que git estaba sincronizado con CC.

    –Matt Curtis

    27 de febrero de 2010 a las 0:14

  • Gracias por el gran nivel de detalle y el enlace al artículo del blog.

    – Bas Bossink

    28 de febrero de 2010 a las 20:13

1646745976 362 ¿Como conectar git a ClearCase
charleso

Si bien puede que no sea sin algunas verrugas (has sido advertido), siento que debo mencionar que he escrito una especie de puente.

http://github.com/charleso/git-cc

Establecer un puente entre los dos sistemas no es fácil, y desearía que mi solución fuera la mitad de buena que git-svn. Una gran limitación es que realmente está limitado a duplicar una sola secuencia; git-cc no puede clonar todas sus sucursales de Clearcase (tan bueno como sería). Sin embargo, dado que la mayoría de los scripts alternativos se resuelven en torno a una sola vista de Clearcase, no está peor (IMO).

Personalmente, encuentro que la historia es bastante importante y lo que les falta a otras soluciones es la importación de la historia a Git. Poder ejecutar git-blame en archivos y ver a sus autores reales es bastante útil de vez en cuando.

Si nada más, git-cc puede manejar el paso ‘git log –name-status’ mencionado anteriormente en la solución de Matt anterior.

Sin duda, tengo curiosidad por saber qué piensan VonC y Matt (y otros) sobre esto, ya que estoy de acuerdo en que cualquier puente hacia Clearcase está plagado de dificultades y puede ser más problemático de lo que vale.

  • Lo investigaré. +1 por siquiera intentarlo;)

    – VoC

    20 de marzo de 2010 a las 8:11

  • Yo tercero eso! +1 hacia el desarrollo de git-cc 🙂

    –Matt Curtis

    23 de marzo de 2010 a las 0:53

  • Tenemos un repositorio ClearCase nuevo, y como CCRC 7.1.x tiene errores inútiles, me di por vencido hoy y probé su importador de Python. Guau. La historia se importó sin dolor y parece seguir el rastro principal limpiamente; ¡y es rápido! ¡Gracias!

    –James Blackburn

    31 de diciembre de 2010 a las 18:55


¿Como conectar git a ClearCase
VonC

El único proceso que suelo seguir es:

  • instantánea de cd dentro de un ClearCase view/vobs/myComponent
  • git inicializar

Eso me permite considerar un componente ClearCase como un repositorio de Git.
Luego puedo hacer todas las ramificaciones y confirmaciones “privadas” que quiero dentro de ese repositorio, haciendo que el archivo se pueda escribir cuando lo necesito (posible dentro de una vista de instantánea).

Una vez que tengo una confirmación final estable, actualizo mi vista de instantáneas, que enumera todos los archivos “secuestrados”: los reviso y los vuelvo a registrar en ClearCase.

Teniendo en cuenta los límites de Git, un repositorio por componente ClearCase (UCM) tiene el tamaño adecuado para un repositorio de Git.
Consulte también ¿Cuáles son los conceptos básicos de clearcase que todo desarrollador debe conocer? para una comparación entre ClearCase y Git.

Queda la idea:

  • sin git-cc
  • no hay necesidad de importar todos la historia de ClearCase (que no tiene noción de referencia del repositorio, a diferencia de las revisiones de SVN)
  • creación de un repositorio Git dentro de una vista ClearCase para confirmaciones intermedias
  • Confirmación final de Git reflejada en la vista de ClearCase a través de un registro de todos los archivos modificados.

  • @neves: no directamente, ya que necesita una secuencia de comandos para consultar el repositorio de git, solicitar cualquier archivo renombrado (Git podrá detectar archivos renombrados), verifique el directorio de origen en ClearCase, verifique el directorio de destino (si es diferente del directorio fuente), realice un ‘cleartool move src/file dst/renamedFile‘, registrarse src y dst directorio.

    – VoC

    10 de diciembre de 2011 a las 3:47

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad