Alternativas de código abierto a Clearcase

Question

Estoy ayudando a configurar el SCM para un nuevo programa y actualmente estamos en el proceso de decidir sobre un VCS.

Los principales contendientes en este punto son SVN, ClearCase, SVN+DVCS y solo un DVCS.

Por el momento, el equipo se inclina por SVN o SVN+DVCS.Queremos evitar los gastos y costos administrativos de ClearCase, pero queremos el flujo de trabajo y las opciones de control de versiones que ofrece.También presenté la opción de utilizar un DVCS y se está considerando la idea.

Para DVCS, estamos considerando Mercurial, Bazaar y Git.El equipo se siente cómodo con SVN, pero no creo que ofrezca la versatilidad necesaria, razón por la cual estamos considerando el DVCS además de la opción SVN.

¿Alguien tiene algún consejo (por ej.herramientas y procesos existentes) para poner en marcha dicha configuración?

Las preocupaciones incluyen:

• Facilidad de configuración
• Configuración de flujos de trabajo (desarrollo <-> revisiones de código -> prueba -> troncal, luego troncal -> rama de prueba de integración -> lanzamiento con correcciones de errores colocadas en las ramas de lanzamiento), auditoría (se encontró un error, cuándo se introdujo)
• Generando métricas
• Curva de aprendizaje razonable para desarrolladores acostumbrados a ClearCase.
• desarrollo de ventanas
• Integración del rastreador de problemas (probablemente será Redmine, aunque no está escrito en piedra)

Answer 1

Como administrador de ClearCase, descartaría esa herramienta a menos que tenga un flujo de trabajo de fusión complejo.

El flujo de trabajo que menciona implica poder bifurcar, reparar y luego volver a fusionar fácilmente , que no debería estar a favor de SVN.

La trampa más grande cuando estás acostumbrado a ClearCase (ClearCase espacialmente no UCM) es la " composición " de una especificación de configuración.
Si elige un DVCS (Mercurial, Bazaar o Git, ya que funciona muy bien en Windows ), no ser capaz de obtener el mismo & "; efecto de herencia &"; - (cuando selecciona diferentes versiones con diferentes reglas de selección sucesivas - : como se dijo en esa respuesta:

  

En un VCS puramente central, puede definir su espacio de trabajo (en ClearCase, su & "; ver &"; ya sea instantánea o dinámica) con las reglas que desee.
  Eso no sería práctico en un DVCS (como en & Quot; Distributed & Quot;): cuando está haciendo una ramificación con él, debe hacerlo con un punto de partida y un contenido claramente definido y fácilmente replicable a otros repositorios.

Si está utilizando ClearCase UCM, eso significa identificar conjuntos coherentes de archivos, que solo se pueden lograr a través de, por ejemplo, Submódulos Git .
La complejidad es mayor con esos DVCS, ya que no registran las dependencias entre módulos (o & "; Conjunto de archivos &";) De la manera en que lo hace ClearCase UCM.

Entonces, para recapitular:

• Facilidad de configuración: todos los DVCS mencionados son fáciles de configurar. Lo que debe tenerse en cuenta es la administración en términos de acceso del usuario.
• Configuración de flujos de trabajo: un DVCS admite cualquier tipo de flujo de trabajo, incluso uno centralizado, o uno público-privado, o ... En cuanto a encontrar un error, todos admiten algún tipo de bisect process .
• Generación de métricas: si con eso quiere decir & "; métricas sobre el código administrado &"; todas ellas admiten algún sistema de registro completo capaz de mostrar mucha información sobre lo que ha cambiado.
  Pero en términos de & Quot; métricas sobre la herramienta & Quot; (velocidad de un proceso o espacio ocupado por los datos), las herramientas DVCS mencionadas se consideran mucho más rápidas que SVN (consulte aquí como ejemplo ).
• Curva de aprendizaje razonable para los desarrolladores que usan ClearCase: la GUI puede ser un factor para aliviar la curva de aprendizaje, pero un DVCS es muy diferente de ClearCase, ya que esto " conceptos básicos " la respuesta ilustra.
• Desarrollo de Windows: todos funcionan bien en la plataforma de Windows, con quizás una ligera ventaja (mejor integración) para Mercurial o Bazaar.
• Integración del rastreador de problemas (probablemente será Redmine, aunque no está establecido): Redmine ahora admite la mayoría de ellos (y no solo SVN como lo hizo al principio)

Answer 2

¿Cuál es el problema con Git? Estoy usando Git en Windows en este momento. Funciona bien Git Extensions es muy útil si desea una integración de explorador, si ese es su problema.

Answer 3

No tengo experiencia con clearcase pero espero que lo siguiente ayude un poco. Su pregunta deja fuera varios datos que tendría en cuenta antes de decidir. Primero, ¿cuánto código fuente tendrás? Si bien SVN es bueno en proyectos medianos a grandes para proyectos realmente grandes como el kernel de Linux, Git proporcionará un rendimiento mucho mejor. Segundo, ¿qué IDE estás usando? Si bien Mercurial, Git y SVN tienen complementos de estudio visual y eclipse de muy buena calidad. De acuerdo con el artículo de Wikipedia sobre Redmine, se integrará cualquiera de los sistemas SCM que está viendo. El siguiente blog puede ser útil para usted, ya que está escrito para comprar a un tipo que escribe un sistema SCM para ganarse la vida. http://www.ericsink.com/

Answer 4

Si pudiera eliminar el requisito de que necesita ejecutarse en Windows, le recomendaría mirar Aegis .