Migrando Clearcase a X

Me pidieron que eligiera una alternativa de código abierto para Clearcase-UCM, y necesito un consejo sobre cuál sería la mejor opción. A continuación se presentan algunos parameters que he recostackdo:

  • La mitad de los equipos de desarrollo utilizan la vista de integración, la vista de desarrollo, la rebase y la metodología de entrega. El rest solo funciona directamente en su flujo de integración con vistas privadas como si fuera troncal.
  • todos los equipos usan líneas de base para las versiones de labeldo.
  • Afirman que enfrentan problemas de fusión con Clearcase-UCM, por lo que la alternativa debe tener capacidades de fusión bien diseñadas.
  • Mantenimiento cero: no hay administrador de VCS para la herramienta.
  • Desarrollo basado en Windows, por lo que la herramienta debe tener un buen soporte win32.
  • Integración IDE (eclipse).
  • Soporte para Mac-OS.
  • Es bueno tener: herramienta de migration.

¿Qué herramienta se ajustará a ambos methods de trabajo (ninguno de los grupos adoptará el otro método)? Tengo svn, mercurial y git como alternativa hasta ahora. ¿alguno de ellos encajará? ¿Hay alguna otra opción?

No puedo hablar por la herramienta de migration, pero mercurial ha funcionado muy bien para nosotros. Tenemos una mezcla de gente de WinXP, Mac OS X y Linux y no ha habido inconvenientes. No uso un IDE, pero creo que Aptana adquirió el grupo pydev (Python para Eclipse) así que no me sorprendería mucho si lo tuvieran.

Al usar UCM y crear una línea de base, identifica de manera efectiva una revisión de un subgrupo pnetworkingefinido de un repository (el componente UCM definido dentro de un Vob, a less que haya definido uno todo Vob como componente)

Entonces, si está utilizando SVN, Git o Mercurial, debe darse count de que cada uno de sus componentes UCM será en realidad un repository (SVN-Git-o-Mercurial).

Además, deberá recrear la noción de dependencies de UCM (las "dependencies de reference de edición", que ninguna de esas herramientas tiene).

El principio de aproximación más cercano se describe en esta respuesta SO : se puede hacer pero sigue siendo manual.

Nota: "Mantenimiento nulo: no hay administrador de VCS para la herramienta." … errr buena suerte con esa:

  • apoyo
  • DRP (plan de recuperación de desastres)
  • acceso correcto para ciertos repositorys con contenido "sensible"
  • scripting y encapsulamiento del cliente para ciertas operaciones
  • ….

Independientemente de la herramienta que elija, necesitará un administrador (no a time completo, pero sí involucrado en las tareas administrativas)


En cuanto a la "trazabilidad", representada principalmente por las actividades en UCM, pero también por la jerarquía de flujos que permite definir un flujo de trabajo de fusión, no se traduce bien en Git / Mercurial: esas herramientas son diferentes.

Para Git, un commit es lo más parecido a una actividad, especialmente porque un ' git rebase -i ' (rebase interactivo) te permite networkingefinir el contenido de un commit (un poco como cuando seleccionas nuevamente una actividad para un nuevo checkout)
Con respecto a la fusión, dado que son tan fáciles en Git o Mercurial, no existe un "flujo de trabajo de fusión" real formalmente definido a través de la operación de entrega / rebase.
Por el contrario, las twigs privadas se crean y utilizan / fusionan según lo considere el usuario, y algunas de esas twigs se publican en otro repository externo.

Hasta cierto punto, las partes técnicas son las más fáciles de tratar: puedes usarlas con MacOSX o no puedes, etc. Las partes difíciles son los "services" que compras como parte de la licencia CC, y esas no lo harán. ser obvio para los desarrolladores, ni a los desarrolladores les importará necesariamente.

Los activos de su empresa estarán ubicados en repositorys gestionados por la herramienta que select y pasar de una herramienta a otra no siempre es tan fácil. Entonces, mucho depende del ciclo de vida de sus productos. ¿Están en el mercado por 6 meses, 6 años o incluso más? El problema con algunas de estas herramientas solo ha estado ahí por algunos años, y están sujetas a la moda hasta cierto punto. Git está a favor, Bazar parece haber perdido el favor.

Mi consejo sería mirar lo que Rational proporciona según su acuerdo actual y tratar de encontrar una herramienta compatible con un proveedor de services que le brinde un service equivalente. Luego compara los costos.

También puede pensar en cómo sacará a sus desarrolladores de ClearCase y en la nueva herramienta. En mi experiencia, las herramientas de migration son 80% de personas. Por el momento pueden quejarse amargamente, pero cuando las cosas no van tan bien con la nueva herramienta en su escenario de cero mantenimiento, entonces su punto de vista puede cambiar … estado allí.

Si tienen problemas para fusionarse, no hay garantía de que ir a otra herramienta lo solucione. Si el problema persiste después de la migration, sabrá que no es la herramienta el problema.

Cualquier herramienta puede ser cero mantenimiento. Se rompe, no lo arregla, y migra a otra 'herramienta del mes'.