¿Método para integrar varios sistemas de control de versiones o elegir uno sobre otros, debido a fusiones y adquisiciones?

11

Las compañías adquieren otras compañías que usan diferentes sistemas de control de versiones.

¿Existe una sabiduría común sobre cómo integrar tales sistemas juntos, por ejemplo, usando un puente Subverson-GIT o incluso decidiendo usar solo una herramienta sobre otra, y cómo migrar entre sistemas?

¿La gente usa un conjunto de criterios para la toma de decisiones, por ejemplo, un equivalente a la prueba "Joel" en el desarrollo de software?

version-control migration therobyouknow
fuente

Respuestas:

11

Para responder la pregunta de migración desde la experiencia personal de varias migraciones:

No tenga miedo de simplemente poner la versión actual del software en el nuevo sistema de control de fuente como la línea base y trabajar desde allí.

La gran mayoría de las veces no necesitará la historia. Esto significa que es una tarea menos que realizar durante la integración y una cosa menos que salga mal.

Los archivos / proyectos que se están desarrollando activamente pronto generarán una nueva historia. Entonces, cuando necesite averiguar por qué se realizó un cambio, es probable que el historial esté en el repositorio actual, ya que será un cambio reciente.

Los archivos / proyectos que eran estables antes de la migración deberían (en igualdad de condiciones) permanecer estables después de la migración, por lo que no necesitará consultar el historial. Descubrimos que si teníamos que investigar un error en un archivo / proyecto tan antiguo, tener el historial no era realmente beneficioso. Siempre que mantenga el antiguo repositorio disponible durante 6 meses / año, tendrá la referencia en tales casos.

ChrisF
fuente
+1 punto justo, solo migre lo que necesita, deje las versiones antiguas en el repositorio anterior heredado. No migres por sí mismo. Este enfoque es una variación del enfoque de la elección entre organizar frente a buscar. Si la búsqueda puede obtener lo que desea rápidamente, siempre no hay necesidad de organizar lo que busca.
therobyouknow
1
+1 IMO la mejor estrategia. Siga usando solo uno, los otros en modo de solo lectura por si acaso.
user281377
1
+1: respuesta más precisa en la parte de migración.
VonC
1
+1: lo suficientemente difícil como para comprender el código existente y mucho menos las últimas tres versiones.
JeffO
1
Convertimos muchos repositorios CVS a SVN utilizando el script cvs2svn, que funcionó muy bien. No recuerdo que nadie haya buscado la historia más allá de los "cambios recientes", por lo que no valía la pena el espacio en disco. Si lo volviera a hacer, simplemente etiquetaría el repositorio CVS, me registraría en SVN como nuevo y luego marcaría el repositorio CVS como de solo lectura.
JBRWilkinson
4

En el aspecto gerencial, se trata principalmente de:

  • soporte : la compañía que lanzará el VCS seguirá estando allí en caso de problemas.
    Es tristemente una de las razones principales por las que todavía se consideran productos tan obsoletos como ClearCase (ClearCase es desde 2003 un ... producto de IBM )
  • costo de la licencia : incluso si existen alternativas de software gratuito, a veces las "licencias grupales" para un VCS pueden negociarse o incluirse en un contrato mucho más amplio que incluye servidores, redes, soporte, etc. Una licencia global para este tipo de producto puede finalizar hasta cuestan mucho menos que el precio público.

Del lado del proyecto, también se trata de:

  • administración : ¿en qué servidor instalará un VCS (o muchos VCS si hablamos de Git, SVN y otros)? ¿Con qué política de respaldo? ¿Qué DRP (Plan de recuperación de desastres)?
  • soporte local : ¿quién tomará el soporte de nivel 1? ¿nivel 2?
  • conocimiento del mercado : ¿está seguro de encontrar suficientes desarrolladores y / o administradores con el conocimiento adecuado para aprovechar este VCS y todas sus características?

Freeware o no, recuerde que un software "gratuito" es gratuito como en "libertad de expresión" (usted es libre de elegir e implementar el que desee), no como en "cerveza gratis" (todavía costará mucho dinero en el servidor , copia de seguridad, administración, soporte, ...)

Los criterios mencionados anteriormente son un comienzo para determinar qué VCS mantener, qué abandonar.
Pero en el último caso, debe considerar:

  • estrategia de migración : ¿puede exportar / importar un historial de proyecto de un VCS a otro?
  • estrategia de puente : ¿tiene sentido tener un historial en dos VCS diferentes?
  • obsolescencia del proyecto : si un proyecto está en estado de mantenimiento / fin de vida útil, podría ser mejor admitir un VCS antiguo por un corto tiempo.
VonC
fuente
+1 buena respuesta, las viñetas resumen los criterios que estoy buscando, y sus explicaciones con ellos también ayudan. Daré una oportunidad a otros antes de aceptar una respuesta. Gracias.
therobyouknow
1

¿Realmente necesitas integrar diferentes sistemas? En nuestro equipo, cada proyecto vive en su propio repositorio y, por lo tanto, sus historias son independientes. No tenemos ningún problema aquí para trabajar con algunos proyectos bajo subversión y otros bajo mercurial, incluso si hay dependencias entre ellos.

Si elige migrar de un VCS a otro, consulte las herramientas de conversión disponibles. Según mi experiencia, no hay ninguna razón técnica para abandonar las historias de los proyectos.

Editar

Creo que entendí algo, que estaba implícito en la pregunta y en otras respuestas. Es el hecho de que los VCS también se usan para administrar dependencias. Sé que es bastante común usar características de VCS como svn:externalsintegrar un repositorio (la dependencia) con otro.

Creo que la razón (técnica) por la que nuestro equipo no siente la necesidad de unir (o integrar) nuestros 2 sistemas diferentes es que tenemos una herramienta separada para administrar las dependencias. Nuestro repositorio no se conoce.

barjak
fuente
¿Necesitas integrar diferentes sistemas? Sí, si el trabajo de un equipo es utilizado por otro equipo. La integración puede ser ajustada o perder dependiendo del nivel de necesidad y los recursos de personal disponibles. No si los proyectos son completamente independientes. La única preocupación que queda es apoyar más de un sistema y si eso se percibe como algo bueno o malo. ¡Bueno si aceptamos que vivimos en un mundo informático variado o malo si pensamos que deberíamos centrarnos y mostrar decisión por su propio bien, eligiendo una herramienta en sí misma que podría ser demasiado solipistista!
therobyouknow
PD. +1 Suerte, barjak, por estar en una organización que tolera un entorno informático variado.
therobyouknow
0

Muchas buenas respuestas. Otra cosa en la que pensar es no dejar que los miembros del equipo se salgan con la suya pensando que cambiar el VC es un gran problema. Habrá un revés con la migración, una curva de aprendizaje, etc., pero si han tenido demasiados problemas, deben cuestionar su nivel de habilidad y / o cooperación.

JeffO
fuente
+1 Un realismo aquí. La gente necesita mantenerse nerviosa, ser valiente y proceder. Los riesgos deben estar bien definidos. Un aprendizaje que estoy viendo y oyendo decir a otras personas en mi lugar de trabajo es que a veces no trabajamos lo suficiente para reducir la incertidumbre / definir claramente los riesgos / contingencias antes de comprometernos. Parece que hay tiempo de sobra para la iteración de corregir / corregir, pero no el tiempo suficiente para hacerlo bien la primera vez. La solución de los problemas se recompensa y se considera una actividad en progreso, incluso si a veces eran innecesarios.
therobyouknow
1
Eso depende de los VCS en cuestión y de qué tan bien se realiza la migración. Pasar de Git o incluso CVS a cualquier VCS de bloqueo será extremadamente discordante.
David Thornley