Clearcase Vs Git version control

version-control

Question

Estamos utilizando el repositorio de varios sitios de clearcase , y con frecuencia es necesario que combinemos y construyamos nuestro sistema. Esta combinación y replicación demora casi 3 días en estar disponible en todos los sitios. Por lo tanto, para ser más eficientes, estamos planeando pasar al control de versiones de Git . ¿Podría por favor informarnos del posible inconveniente que podemos encontrar si nos movemos al Git desde Clearcase?

Answer 1

¿Necesita una herramienta que lo ayude con la administración de la configuración de su software (SCM) o su control de versión [sistema] (VCS)?

Eso es a lo que se reduce la discusión de ClearCase vs Git.

Por así decirlo estás comparando manzanas con naranjas.

Pensar en ClearCase como otro VCS es una visión estrecha de lo que ClearCase es; siga con ClearCase si su objetivo es enviar el producto correcto fuera de su tienda.

Por otro lado, Git es probablemente el mejor VCS en el mercado en este momento (aunque no ofrece ningún soporte de SCM), por lo que puede cambiarlo si su preocupación se está ramificando y fusionando ... son el resultado de una línea de base mal configurada y de vistas configuradas incorrectamente) ... La replicación de VOB apesta, le doy eso.

El inconveniente de su movimiento planificado es que desechará su soporte de herramientas SCM. Y tendrá que enfrentarse a una gran variedad de herramientas y mucho trabajo manual para lograr lo que tenía fuera de la caja con ClearCase.

De todos modos, un buen VCS es la columna vertebral de cualquier SCM, por lo que su cambio a Git podría ser recompensado a largo plazo.

Answer 2

@zzz777: Su pregunta fue hecha en una vista tan centrada en ClearCase que no fue comprensible para las personas que nunca antes habían usado ClearCase. De hecho, Git está a años luz MÁS ALLÁ de ClearCase, son SCM comerciales que necesitan ponerse al día con los sistemas OSS.

Tengo experiencia tanto con ClearCase como con git y puedo decirle que la función Find merges (mis) de ClearCase es el resultado de su diseño (fundamentalmente roto) basado en archivos de versiones, pero en git no necesita una herramienta tan primitiva para fusionar a tu rama privada la rama compartida. ClearCase está orientado a archivos, y los checkin-s están basados ​​en archivos, por eso necesita la utilidad Buscar (archivos) para fusionar, pero git se basa en el compromiso, y ese es el modelo correcto, ya que cuando soluciona un problema o implementa una característica , el conjunto de cambios completo o ninguno de ellos son las únicas opciones que tienen sentido.

Git tiene una característica de combinación muy poderosa y hace lo correcto, y hay dos formas de hacer lo que estás pidiendo (actualizar tu rama privada para que sea la rama compartida + tus cambios).

Lo más obvio es hacer una combinación, así que mientras estás en tu sucursal privada solo haces:

git merge sharedbranch

entonces, si hay conflictos (realmente mucho más raros que en ClearCase), resuélvalos y

git commit

Y eso es. Como beneficio adicional, dado que git tiene todo el historial local, no tiene que perder innumerables horas, si tiene muchos archivos, como en ClearCase, la combinación es increíblemente rápida, cuando ClearCase en una vista dinámica hace una fusionando 10 archivos, git probablemente terminará de fusionar 100, fácilmente.

Usar git merge significa que conservas el historial y si tu historial se veía así antes de la fusión:

o---1---2---3 (sharedbranch)
 /
  a---b---c (privatebranch)

después de la fusión se verá así:

o---1---2---3 (sharedbranch)
 /           /
  a---b---c---m (privatebranch)

Esto preserva el historial de sus cambios y puede permitir que otros revisen su trabajo.

Y recuerde, estos NO son historiales de revisión de archivos, éstos si el historial del árbol, que es el único que tiene sentido almacenar, incluso si las ramas difieren solo en 1 o 2 archivos, el estado que desea conservar es el árbol, no uno archivo.

La segunda opción es usar rebase, lo que significa que usted hace que parezca que todos los cambios se han hecho a partir del último código en la rama compartida.

El comando que usa (de nuevo, mientras está en la rama privada):

git rebase sharedbranch

El árbol de la historia cambiará de:

o---1---2---3 (sharedbranch)
 /
  a---b---c (privatebranch)

a

o---1---2---3 (sharedbranch)
             /
              a''--b''--c'' (privatebranch)

Entonces, si le das a git algo de tiempo para entenderlo, y lo usas un poco, verás cuánto mejor es el modelo de git y qué tan roto está el modelo ClearCase.

Por cierto, el problema del gemelo malvado en ClearCase simplemente no existe en git porque git no rastrea directorios (confía en mí, NO lo necesitas).

Además, si alguna vez tuvo una especificación de configuración que es un poco más complicada con varias ramas y migró archivos de una rama a otra, probablemente sepa lo importante que es el orden de las reglas en la especificación de configuración y lo frustrante que es. Ver versiones antiguas de archivos porque la especificación de configuración es "incorrecta". Eso sucede en ClearCase debido a su diseño base, y, no hace falta decir que ese tipo de basura no puede ocurrir en git.

Entonces, para concluir, git no tiene una herramienta primitiva como "encontrar combinación" porque no la necesita. Tiene un modelo superior y un modelo de combinación superior que realmente funciona. Es increíblemente rápido en comparación con ClearCase (vista estática CCRC o vista dinámica, lo que sea).

El único lugar donde ClearCase podría tener una ventaja es la actualización instantánea de la vista dinámica, pero esto también se ve mitigado por el hecho de que puede escribir una rama de pago de git más rápida que la actualización de las especificaciones de configuración.

Answer 3

Como mencioné en " ¿Cuáles son los conceptos básicos de ClearCase que todo desarrollador debería saber? ", ClearCase podría tener algunas características "descentralizadas" con sus repositorios de sitios múltiples, pero sigue siendo un CVCS en su núcleo:

• tiene un fuerte vínculo con el usuario-id del sistema (que no es relevante en un DVCS, donde no hay un referencial de usuario único).

• tiene un repositorio único para administrar nombres de etiquetas y ramas (admin vob), mientras que usted puede definir una rama de "prueba" en 15 repositorios Git diferentes sin problema (excepto que necesita saber qué es repo1/test , relativo a repos2/test ).

• también centraliza una definición de flujo de trabajo de combinación a través de la jerarquía de Secuencia (UCM) (puede visualizar dónde se supone que debe combinar un trabajo de una Secuencia a otra).

• propone a través de la UCM una definición de subconjunto de códigos (componente), con gestión de dependencias. Git solo tiene submódulos, sin anular / anular el mecanismo de detección.

• gestiona cualquier tipo de archivos, incluso archivos binarios grandes, mientras que un DVCS (cualquier tipo de DVCS) es mejor administrar solo el código fuente.

La conclusión (en nuestra migración de ClearCase a Git) es que implica un buen número de refactorización / reorganización del código fuente para tener repositorios de Git manejables.

Answer 4

He trabajado con Git y ClearCase y una vez que aprendas a usar Git y luego cambias, nunca mirarás hacia atrás. Asegúrese de tener tiempo para capacitar a sus desarrolladores; esta debe ser su máxima prioridad. Git es un enfoque completamente diferente a SCM que ClearCase.

Algunas cosas a considerar (posibles desventajas):

1. Necesitará un verdadero maestro de repositorio, no solo alguien que vigile la fuente, sino alguien que entienda cómo funciona realmente el SCM (no solo lo que una GUI les muestra) y puede manejar su modelo de bifurcación (vea el # 2)
2. Adoptar / desarrollar un modelo de rama robusto. Un gran ejemplo, y uno que he usado es http://nvie.com/posts/a-successful-git-branching-model/
3. Vas a tener que invertir mucho tiempo ayudando a tus desarrolladores a volver a aprender todo lo que pensaron que sabías sobre el uso o la interacción con SCM.

Si puede superar los tres anteriores, entonces hay un pequeño inconveniente (el # 3 es el más difícil). En cuanto a @PAntoine, la mayoría de estos problemas están relacionados con la capacitación. El # 1 tendría que requerir una decisión realmente mala para perder el código fuente. . git reflog le proporcionará acceso a cada compromiso con el repositorio. La única forma de destruir la fuente sería a través de git reflog expire --expire=whatever refs/heads/master , git fsck --unreachable , git prune git fsck --unreachable , y git gc , que solo debe ser manejado por el maestro de repositorio - y luego está El problema universal de un desarrollador que no está cometiendo su fuente (¡D''oh!)

Answer 5

Problemas que he tenido en una oficina de habilidades mixtas profesionales:

1. Historia mutable.
   Puedes hacer algunas cosas realmente tontas (y poderosas) con GIT. Esto puede causar la pérdida de la fuente.
2. Fusión automática.
   Esta es la mejor característica de git. PERO, tuvimos que cerrar el desarrollo durante una semana para encontrar el código fuente que desapareció. MSVS tiene un problema feliz con el cambio aleatorio de los finales de línea y si no se extrae del repositorio con regularidad, se confunde y los cambios se pierden.
3. Orden Push / Pull.
   Clearcase maneja el orden de la fecha y el historial, pero git lo ignora.
4. Puesta en escena.
   Clearcase (al menos UCM) maneja la promoción de sucursales y otras cosas para usted. Git no lo hace. Tendrás que gestionar esto con cuidado.
5. $ ID $
   No existe para git. El seguimiento de la versión de las versiones reales y la detección de problemas al saber cuál es la versión del archivo de origen tendrá que manejarse manualmente. (No estoy seguro de cuál es su proceso de liberación).

Para su repositorio de código final, podría sugerir un repositorio de lanzamiento, ya sea otro sistema de control de origen o un repositorio de git separado, que esté administrado y solo acepte extracciones.

Actualmente estoy usando git para mi proyecto en solitario y está bien. Pero, en una casa de habilidad mixta con una variedad de editores, tendría cuidado. Realmente puedes volarte sin saber con Git.

Tampoco he usado, hg o bzr. Puede que valga la pena verlos ya que algunos de los problemas desaparecen y tienen características para mitigar algunos de los problemas anteriores.

Espero que esto ayude.