¿Cuáles son las mejores prácticas para moverse entre sistemas de control de versiones?

Question

Hay alrededor de 200 proyectos en cvs y al menos 100 proyectos en vss.Algunos son códigos inactivos en modo de mantenimiento.Algunas son aplicaciones heredadas.Algunas son aplicaciones antiguas que ya no se utilizan.Alrededor del 10% están en desarrollo activo.El plan es mover todo para forzar mi fin de año 2009.

¿Alguien ha realizado una gran migración como esta?

¿Alguien ha encontrado las mejores prácticas para pasar de cvs a perforce?O una migración similar.¿Alguna trampa a tener en cuenta?

Answer 1

En el lado de VSS, existen herramientas de conversión disponibles para ayudar con la migración.En su mayoría, pueden mantener el historial de versiones (hay advertencias que se explican en el archivo Léame y en los documentos).He migrado más de 50 proyectos VSS a perforce utilizando la herramienta VSS to perforce.Obtener los datos de VSS puede ser un poco complicado y no muy rápido, pero funciona.Si tiene acceso directo a los discos (es decir,no a través de un recurso compartido de red) al repositorio VSS, la conversión puede ser mucho más rápida.Puedes encontrar información sobre los scripts. aquí.

Hay una página similar para que CVS realice la conversión. aquí, aunque no tengo experiencia directa con eso.Estos enlaces son buenos lugares para comenzar.También puede buscar en las listas de correo de Perforce en la base de conocimientos de Perforce ubicada aquí.Estoy bastante seguro de que es posible que encuentre información sobre la conversión en los archivos de la lista de correo.

Migra primero tus proyectos antiguos.Puede asegurarse de que su proceso funcione.Cuando migramos el código activo a Perforce, me tomé un fin de semana y básicamente eliminé el acceso a los servidores y moví el código a Perforce.Honestamente, fue una migración bastante fácil y cuando la gente regresó el lunes estaba lista para partir.Podría pensar en preparar a sus empleados con hojas de trucos de Perforce después de comenzar a realizar la migración.

Los mayores problemas podrían ser preparar a su gente para usar Perforce.Si lo hubiera hecho de nuevo, habría migrado primero nuestros proyectos activos más pequeños y habría preparado a un número menor de personas para usar Perforce a la vez.Tal como estaban las cosas, tuve que capacitar a más de 120 personas el día 1 después de la migración y eso fue demasiado.Además, asegúrese de que no haya más de 100 personas accediendo a su servidor para una nueva sincronización el día 1.Terminamos desconectando nuestro servidor varias veces durante los primeros días.Usamos un servidor Windows de 32 bits que no recomendaría.Ahora tenemos un servidor Windows de 64 bits y es mucho más robusto.Si puede, yo usaría Linux como sistema operativo para su servidor forzado.Nuevamente, debería haber buena información en el sitio de Perforce sobre el rendimiento.

Answer 2

No he tenido que hacer algo de esta escala, pero tengo algunas ideas.En primer lugar, comience por tomar un proyecto pequeño y sin importancia y migrelo.Eso le dará una idea de los problemas que llevará migrar el resto de los proyectos.Inmediatamente después, debe elegir un proyecto de tamaño mediano, ya que puede haber problemas al migrar un proyecto más grande (por ejemplo, con ramas) que podrían no ser evidentes en un proyecto pequeño.

Asegúrate de dedicar un poco de tiempo a ver lo fácil que es convertir proyectos cvs a vss, o al revés.Si convertir de vss a perforce es una verdadera molestia, puede convertir vss a cvs y luego a perforce.No dedique días a ello, pero podría sacarlo de una situación difícil.Creo que la clave aquí es ir incrementalmente.

Las copias de seguridad son buenas.Período.

Considere una fecha límite, y cualquier proyecto que esté inactivo y que sea anterior a esa fecha debe suspenderse.Consulte la revisión final y guárdela en Perforce.¿Realmente necesitas un código visual básico de 15 años?

Answer 3

Hagas lo que hagas, mantén los repositorios antiguos en modo de solo lectura en algún lugar.

Answer 4

Perdóneme por responder una pregunta con una pregunta, pero no Forzosamente proporcionar herramientas para esto?¿O al menos documentación?Estaría golpeando a mi vendedor de Perforce...

Answer 5

Considere no migrar proyectos muertos e inactivos.Simplemente ponga sus repositorios en modo de solo lectura.Los datos seguirán estando disponibles si es necesario y usted ahorrará el tiempo y el esfuerzo de migrarlos.Simplemente migre el 10% que está en uso.Documente el proceso minuciosamente.

Si uno de los proyectos no migrados resucita en algún momento en el futuro, podrá migrarlo fácilmente utilizando su documentación como referencia.

Answer 6

Migramos nuestro repositorio svn con una herramienta que escribimos y simplemente tomamos la revisión principal de nuestros proyectos de starteam.

Tenga cuidado con las diferencias entre los registros de un solo archivo (CVS) y los conjuntos de cambios de varios archivos (Perforce).

Cuidado con las sucursales: espacio separado (CVS) vs.ramas en el espacio de ruta de archivo (Perforce).