Cómo unir git a ClearCase?

Recientemente utilicé git svn y lo disfruté mucho. Ahora estoy comenzando un nuevo proyecto en un cliente diferente. En ese sitio, el SCM de elección es ClearCase. No he encontrado un equivalente horneado de git svn para ClearCase. ¿Hay alguien que haya intentado usar git localmente como front-end de ClearCase usando algunos trucos, configuraciones o scripts con algún éxito? Si es así, ¿puedes explicar el método utilizado?

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

Usamos dos directorys, uno para la instantánea de ClearCase y el repository maestro de git, que compartimos entre todo el equipo y nunca editamos files, y otro para nuestro directory de "trabajo".

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

 % git init
 % git add ** / *. cxx ** / *. h ** / Makefile (y así sucesivamente)
 % git commit -m "initial"

Luego clona en tu directory de trabajo:

 % mkdir ~ / work
 % git clone / ruta / a / repos

Trabajar en el directory de trabajo, en una twig:

 % git checkout -b function
 % ... editar / comstackr ...
 % git agregar -u
 % git commit

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

A continuación, fusione la twig en el maestro volviéndola a establecer para evitar una fusión automática:

 % git checkout master
 % git pull
 Función de pago% git
 % git rebase master
 % git checkout master
 Función de fusión% git
 % git branch -d feature

 % git diff - estado del nombre origen / maestro

Prepare la vista ClearCase revisando / mkelem / rmname los files modificados / nuevos / eliminados, basándose en la salida de git diff --name-status . Usamos un script enrollado a mano para hacer esto. No olvides echar un vistazo a los directorys que tienen files agregados / eliminados:

Luego, devuelva las cosas de git y regístrese con ClearCase:

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

Parece una gran cantidad de commands, pero esto incluye la configuration, y su flujo de trabajo diario no utiliza muchos commands. Puedes build trivialmente un script en el paso de push-back-to-ClearCase, y descubrir / mostrar a tu equipo todas las cosas geniales extra git gradualmente a medida que todos se acostumbran al flujo de trabajo básico.

La verdadera belleza de este sistema es, después de un time cuando todos son competentes con git, puedes deshacerte de ClearCase y de todas las tareas y honorarios de mono relacionados. Tal vez le den al chico ClearCase de la compañía unas vacaciones muy necesarias y algo de reciclaje con los ahorros. (Tristemente, en mi compañía, las cosas de git eran todas skunkworks, y nos hemos mudado a Subversion, ¡¡¡Forwards de ClearCase, pero al revés de "git"!)

Recomiendo encarecidamente que utilice la secuencia de commands pristine de ClearCase Globally, Git Locally , que se ejecuta en la vista de instantáneas de ClearCase y garantiza que git y él estén sincronizados. Configuramos esto como un trabajo cron que se ejecutó dos veces al día, y también lo ejecutamos de forma manual cada vez que estábamos a punto de retroceder a git. Lamentablemente, el enlace a la publicación del blog ya no es válido. Sin embargo, la secuencia de commands todavía está disponible en Github .

Si bien puede no ser sin algunas verrugas (ha sido advertido), creo que debo mencionar que he escrito un puente de classs.

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

El 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 estás realmente limitado a duplicar una sola transmisión; git-cc no puede clonar todas sus twigs Clearcase (tan bueno como eso sería). Sin embargo, dado que la mayoría de los scripts alternativos se resuelven en torno a una sola vista Clearcase, no está en peor situación (IMO).

Personalmente encuentro la historia bastante importante y lo que otras soluciones carecen es su import de historia en Git. Ser capaz de ejecutar git-blame en los files y ver a sus verdaderos autores es bastante útil de vez en cuando.

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

Ciertamente tengo curiosidad por escuchar lo que piensan VonC y Matt (y otros), ya que estoy de acuerdo en que cualquier puente hacia Clearcase está lleno de dificultades y puede ser más problemático de lo que vale.

El único process que suelo seguir es:

  • cd de instantánea dentro de una view/vobs/myComponent ClearCase view/vobs/myComponent
  • git init.

Eso me permite considerar un componente ClearCase como un repository Git.
Luego puedo hacer todas las confirmaciones de bifurcación y "privadas" que desee dentro de ese repository, haciendo que el file pueda escribirse cuando lo necesite (es posible dentro de una vista de instantánea).

Una vez que tengo un compromiso final estable, actualizo mi vista de instantánea, que enumera todo el file "secuestrado": los compré y los devuelvo a ClearCase.

Teniendo en count los límites de Git , un componente de repository por ClearCase (UCM) es el tamaño correcto para un repository de Git.
Ver también ¿Cuáles son los conceptos claros básicos que todo desarrollador debe saber? para una comparación entre ClearCase y Git.

La idea permanece:

  • no git-cc
  • no es necesario importar todo el historial de ClearCase (que no tiene noción de línea de base del repository, a diferencia de las revisiones de SVN)
  • creación de un repository de Git dentro de una vista de ClearCase para confirmaciones intermedias
  • la confirmación final de Git se reflejó en la vista de ClearCase a través de un logging de todos los files modificados.