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?
Respuestas:
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.
En el aspecto gerencial, se trata principalmente de:
Del lado del proyecto, también se trata de:
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:
¿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.
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.
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.