Práctica de control de versiones para reescrituras

Desarrollamos un producto (prototipo) P_OLD en el lenguaje X y ahora lo estamos reescribiendo desde cero como P_NEW en el lenguaje Y.

Como P_NEW y P_OLD son el mismo producto:

¿Debería P_NEW ser solo una rama de P_OLD o debería ser su propio repositorio?

¿Cuál es la forma habitual de manejar cambios tan grandes desde una perspectiva de control de versiones?

Es casi seguro que quieres un nuevo repositorio.

El propósito del repositorio es:

• para rastrear el historial y los cambios para que pueda compararlos fácilmente
• para administrar sucursales y fusiones en lugar de simplemente enviar por correo electrónico archivos de parches y aplicarlos a directorios de trabajo manualmente

Si está reescribiendo totalmente un proyecto desde cero, entonces no tiene sentido poner la reescritura en el mismo repositorio. No podrá aplicar parches escritos en el idioma anterior a su reescritura. Cambiar los repositorios no hará que la historia en el antiguo repositorio desaparezca, y si cambias no tendrás ninguna etapa intermedia extraña en la que tengas dos idiomas dando vueltas en tu repositorio.

La única razón por la que incluso consideraría mantener el repositorio al cambiar los idiomas sería si a) los idiomas son tan similares que el código a menudo se puede copiar y pegar de uno a otro sin hacer ningún cambio, o b) tiene un proyecto en el que la mayoría del contenido funcional en el control de versiones es algo así como plantillas en un lenguaje de plantillas que está reteniendo, y el idioma del núcleo que está cambiando se traducirá línea por línea a otro idioma (e incluso entonces solo si sabe necesitará seguir iterando las plantillas durante la migración).

Siempre pongo reescrituras en nuevos repositorios yo mismo. De esa manera, las compilaciones, las pruebas y las implementaciones se pueden hacer de forma independiente.

Cuando reescribe un proyecto en otro idioma, a menudo hay muy poca similitud en cualquiera de esas tareas, como compilar, ejecutar pruebas e implementar. Se ahorrará dolor si solo los aísla en su propio repositorio. Entonces solo tendrá que preocuparse por el dolor de cómo va a gestionar la transición del usuario y los datos del sistema antiguo al nuevo; eso siempre es divertido. :)

Si sus sistemas son lo suficientemente modulares y compatibles con enlaces, se beneficiaría de un único repositorio y compilación. Por ejemplo, si el sistema C se está reescribiendo en C ++, el código C ++ podría llamar a la funcionalidad existente y reemplazarla gradualmente.

Sin embargo, incluso en este caso, algunos podrían argumentar a favor de comenzar un nuevo repositorio en el que el código antiguo relevante se extraiga según sea necesario.