Pratique de contrôle de version pour les réécritures

Nous avons développé un produit (prototype) P_OLD dans la langue X et nous le réécrivons à partir de zéro en tant que P_NEW dans la langue Y.

Puisque P_NEW et P_OLD sont le même produit:

P_NEW devrait-il simplement être un brach de P_OLD ancien ou devrait-il être son propre référentiel?

Quelle est la manière habituelle de gérer des changements aussi importants dans une perspective de contrôle de version?

Vous voulez presque certainement un nouveau référentiel.

Le référentiel a pour objectif:

• pour suivre l'historique et les changements afin de pouvoir les comparer facilement
• pour gérer les branches et les fusions plutôt que d'envoyer simplement des fichiers correctifs par e-mail et de les appliquer manuellement aux répertoires de travail

Si vous réécrivez totalement un projet à partir de zéro, il est inutile de mettre la réécriture dans le même référentiel. Vous ne pourrez pas appliquer de correctifs écrits dans l'ancienne langue à votre réécriture. Changer de repos ne fera pas disparaître l'historique de l'ancien référentiel, et si vous changez, vous n'aurez pas d'étapes intermédiaires étranges où vous aurez deux langues dans votre référentiel.

La seule raison pour laquelle j'envisagerais même de conserver le référentiel lors du changement de langue serait si a) les langues sont si similaires que le code peut souvent être copié-collé de l'une à l'autre sans apporter de modifications, ou b) vous avez un projet dans lequel la majorité du contenu fonctionnel du contrôle de version est quelque chose comme des modèles dans un langage de modèles que vous conservez, et la langue du noyau que vous modifiez soit traduite ligne par ligne dans une autre langue (et même alors seulement si vous savez vous devrez continuer à itérer les modèles pendant la migration).

Je mets toujours les réécritures dans de nouveaux référentiels moi-même. De cette façon, les builds, les tests et les déploiements peuvent tous être effectués indépendamment.

Lorsque vous réécrivez un projet dans une autre langue, il y a souvent très peu de similitudes dans l'une de ces tâches comme la construction, l'exécution de tests et le déploiement. Vous vous épargnerez de la peine si vous les isolez simplement dans leur propre référentiel. Ensuite, vous n'aurez qu'à vous soucier de la façon dont vous allez gérer la transition des utilisateurs et des données de l'ancien système vers le nouveau; c'est toujours amusant. :)

Si vos systèmes sont suffisamment modulaires et compatibles avec les liens, vous bénéficierez d'un référentiel et d'une construction uniques. Par exemple, si le système C est en cours de réécriture en C ++, le code C ++ peut appeler des fonctionnalités existantes et les remplacer de manière incrémentielle.

Cependant, même dans ce cas, certains pourraient plaider pour le démarrage d'un nouveau référentiel dans lequel l'ancien code pertinent est extrait selon les besoins.