Migrazione del codice base - vecchio sistema di controllo delle versioni su moderno

Ristrutturare tutto completamente durante la migrazione probabilmente significa che si presenta un alto rischio di rompere i processi di generazione esistenti. Ci penserei due volte prima di percorrere quella strada. L'alternativa migliore è quella di effettuare prima la migrazione 1: 1 e modificare la struttura in seguito , passo dopo passo. Qualsiasi sistema di versioning moderno registrerà le modifiche strutturali per te, quindi se rompi qualcosa durante la ristrutturazione, il sistema di versioning sarà la tua rete sicura.

(Ok, forse puoi lasciare fuori il codice che non è in uso e non più in manutenzione, supponendo che tu possa isolarlo facilmente dalle altre parti. Ma se no, meglio migrarlo prima ed eliminarlo in seguito, solo come sopra).

E per quanto riguarda la cronologia delle revisioni? Quando abbiamo migrato alcuni anni fa da CVS a SVN, mantenere intatta la storia era uno dei nostri principali requisiti e posso dirvi che non ci siamo mai pentiti. Quindi se vedi la possibilità di migrare la cronologia, prendila. Molto probabilmente la modifica della struttura durante la migrazione non lo consentirà, ma semplicemente "scaricare tutti i dati e importarli nel nuovo sistema" non manterrà la cronologia. L'alternativa migliore è creare qualche script (o cercare sul Web se qualcuno lo ha già fatto per il tuo) che riproduce tutti i commit dal vecchio sistema a quello nuovo.

Una parola sull'idea di strutturare "per lingua". Il mio team ha ereditato questo repository da un altro gruppo di sviluppatori che pensava che strutturare "per lingua" fosse una buona idea. Da quell'esperienza, posso dirti che non è assolutamente così. Almeno, non se vuoi tenere insieme le cose che appartengono insieme, e il tempo di vita del tuo software è di diversi anni. Questo perché a volte ci saranno cambiamenti nella lingua di un sottosistema, o uno dei tuoi sottosistemi sarà esteso da un altro strumento o programma scritto in una lingua diversa rispetto al resto. E se la gerarchia delle cartelle nel tuo ambiente di produzione avrà delle somiglianze con la gerarchia delle cartelle del tuo ambiente di sviluppo, strutturare "per lingua" è controproducente, dal punto di vista dell'utente, la lingua in cui un determinato prodotto è scritto non davvero importante.

Sembra che tu abbia una certa flessibilità nella tua migrazione della base di codice.

Un'opzione potrebbe essere quella di fare una "pausa pulita" in cui si imposta il nuovo sistema in base alle migliori pratiche più recenti alle quali si desidera aderire. In tal caso, puoi esportare tutto ciò che desideri dal vecchio sistema e importarlo nel nuovo in base a qualsiasi struttura abbia senso. Non devi legarti a vecchie (90?) Decisioni.

L'altro estremo è quello di provare a migrare al nuovo sistema pur essendo severo nel mantenere il più possibile la struttura legacy. Ad esempio, potresti voler importare tutta la cronologia di Visual Sourcesafe nel nuovo sistema (messaggi di commit, autori, ecc.) Quindi ti riorieni lentamente in qualunque struttura / organizzazione più recente desideri.

Ci sono pro e contro ad entrambi gli estremi e puoi sempre scegliere qualcosa nel mezzo. Dovrai considerare quali tipi di requisiti hai (o vuoi) in atto. Ad esempio:

• Hai bisogno della cronologia completa del commit o puoi lasciarla (guarda su Sourcesafe se necessario)?
• Quale livello di coerenza ci si aspetta dai tuoi sviluppatori (o altri che accedono al repository)? La ristrutturazione sarà un problema?
• Quali sono le differenze tra Sourcesafe e il nuovo sistema di controllo della versione? Per esempio. centralizzato vs. distribuito. In che modo ciò influenzerà le tue decisioni?

Per quanto riguarda una struttura generale e una metodologia, non sono sicuro che esista davvero per molte variabili sconosciute (come il sistema a cui ti stai spostando, o dettagli aggiuntivi sul tuo progetto). Se fornisci maggiori dettagli, potresti ottenere una risposta migliore.

Ma alla fine della giornata spetta a te e al tuo team decidere quale sia il migliore.

Semplicemente inoffensivo, basandomi sui dettagli che mi hai fornito, mi inclino personalmente verso l'estremo "clean break" e uso un git o mercurial come DVCS. Utilizzare più repository per ogni raggruppamento logico / libreria / sistema. Trascorri un po 'di tempo per impostare tutto in un modo nuovo e fresco che consenta ai tuoi nuovi sviluppatori di iniziare senza il bagaglio della vecchia struttura.