Cómo unir git a ClearCase?

Question

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?

Answer 1

Aquí es un método que evita secuestros, que nuestro equipo utiliza este método con bastante éxito durante más de un año, hasta que nos retiramos ClearCase para Subversion (por política de la empresa, a pesar de que es un paso atrás para nuestro equipo - estábamos básicamente simplemente usando ClearCase como un sistema de archivos tonto, y virtualmente trabajando nativamente en git, pero ahora estamos usando el puente git-svn que no es tan bueno como el git nativo.)

Utilizamos dos directorios, uno para el ClearCase snapshot y master git repo, que compartimos entre todo el equipo y nunca editamos archivos, y uno para nuestro directorio de "trabajo".

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

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

Entonces clon en el directorio de trabajo:

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

trabajo 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 pristine (que siempre s para nosotros, porque lo compartimos entre el equipo, y todos usamos git).

luego fusionar la rama en el maestro de rebase que, para evitar una fusión automática comprometen:

 
% 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 

Preparar la vista ClearCase por el control de/mkelem/rmname nuevos archivos modificados// remueven, basan fuera de la salida de git diff --name-status. Usamos un script enrollado a mano para hacer esto. No se olvide de revisar todos los directorios que han añadido/archivos eliminados:

A continuación, empuje el material git atrás, y comprobar con ClearCase:

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

Parece que una gran cantidad de comandos, pero esto incluye configuración y su flujo de trabajo diario no usa muchos comandos. Puedes construir 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 belleza real de este sistema es que, pasado un tiempo, cuando todos sean 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. (Lamentablemente en mi empresa las cosas git fue Skunkworks todos, y nos hemos movido a Subversion - delanteros de ClearCase pero al revés de GIT)

I fuertemente recomiendo que utilice la secuencia de comandos de pristineClearCase Globally, Git Locally, que se ejecuta en el Vista de instantáneas de ClearCase y lo asegura y git 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 comandos todavía está disponible en Github.

Answer 2

El proceso por lo general sigo es:

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

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

Una vez que tengo una confirmación final estable, actualizo la vista de instantánea, que enumera todo el archivo "secuestrado": los compré y los vuelvo a registrar en ClearCase.

Considerando el Git limits, un componente de repositorio por ClearCase (UCM) es el tamaño correcto para un repositorio de Git.
Vea también What are the basic clearcase concepts every developer should know? para una comparación entre ClearCase y Git.

La idea sigue siendo:

• sin git-cc
• hay necesidad de importar todo la historia de ClearCase (que no tiene noción de la línea de base del repositorio, a diferencia de las revisiones SVN)
• creación de un repositorio de Git dentro de una vista de ClearCase para confirmaciones intermedias
• final Git confirmado en la vista de ClearCase mediante una comprobación de todos los archivos modificados.

Answer 3

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

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

puente entre los dos sistemas no es fácil, y me gustaría que mi solución era como media tan bueno como 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 ramas 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 importación de historial en Git. Ser capaz de ejecutar git-blame en los archivos 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.

Tengo curiosidad por escuchar lo que VonC y Matt (y otros) piensan de 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.