Pratica di controllo della versione per Rewrites

Abbiamo sviluppato un prodotto (prototipo) P_OLD nella lingua X e ora lo stiamo riscrivendo da zero come P_NEW nella lingua Y.

Poiché P_NEW e P_OLD sono lo stesso prodotto:

P_NEW dovrebbe essere solo un brach di P_OLD vecchio o dovrebbe essere il suo repository?

Qual è il solito modo di gestire cambiamenti così grandi da una prospettiva di controllo della versione?

Quasi sicuramente vuoi un nuovo repository.

Lo scopo del repository è:

• per tenere traccia della cronologia e delle modifiche in modo da poterle confrontare facilmente
• per gestire i rami e le fusioni anziché semplicemente inviare per posta elettronica file patch e applicarli manualmente alle directory di lavoro

Se stai riscrivendo completamente un progetto da zero, non ha senso mettere la riscrittura nello stesso repository. Non sarai in grado di applicare patch riscritte nella vecchia lingua alla tua riscrittura. Il cambio di repository non farà scomparire la cronologia nel vecchio repository, e se si cambia non si avranno strane fasi intermedie in cui ci sono due lingue che iniziano a girare nel repository.

L'unico motivo per cui prenderei in considerazione la possibilità di conservare il repository quando si cambiano le lingue sarebbe se a) le lingue sono così simili che il codice può spesso essere incollato dall'una all'altra senza apportare modifiche, oppure b) hai un progetto in cui la maggior parte dei contenuti funzionali nel controllo versione è qualcosa come modelli in una lingua di template che stai conservando, e la lingua del core che stai cambiando viene tradotta riga per riga in un'altra lingua (e anche solo se conosci dovrai continuare a ripetere i modelli durante la migrazione).

Metto sempre da solo le riscritture in nuovi repository. In questo modo le build, i test e le distribuzioni possono essere eseguiti in modo indipendente.

Quando riscrivi un progetto in un'altra lingua, spesso c'è poca somiglianza in una di quelle attività come la costruzione, l'esecuzione di test e la distribuzione. Ti risparmierai dolore se li isolerai nel loro repository. Quindi dovrai solo preoccuparti del dolore di come gestirai la transizione dell'utente e dei dati dal vecchio sistema al nuovo; è sempre una cosa divertente. :)

Se i tuoi sistemi sono sufficientemente modulari e compatibili con i collegamenti, trarrai vantaggio da un unico repository e build. Ad esempio, se il sistema C viene riscritto in C ++, il codice C ++ potrebbe chiamare la funzionalità esistente e sostituirla in modo incrementale.

Tuttavia, anche in questo caso alcuni potrebbero obiettare per l'avvio di un nuovo repository in cui viene inserito il vecchio codice pertinente come richiesto.