Metodo per integrare vari sistemi di controllo delle versioni o sceglierne uno rispetto agli altri, a causa di fusioni e acquisizioni?

Per rispondere alla domanda di migrazione dall'esperienza personale di diverse migrazioni:

Non abbiate paura di inserire la versione corrente del software nel nuovo sistema di controllo del codice sorgente come linea di base e di lavorare da lì.

La maggior parte delle volte non avrai bisogno della storia. Ciò significa che è necessario eseguire un compito in meno durante l'integrazione e una cosa in meno da sbagliare.

I file / progetti che vengono attivamente sviluppati genereranno presto una nuova cronologia. Quindi, quando hai bisogno di scoprire il motivo per cui è stata apportata una modifica, è probabile che la cronologia si trovi nel repository attuale poiché sarà una modifica recente.

File / progetti stabili prima della migrazione (a parità di condizioni) rimangono stabili dopo la migrazione, quindi non è necessario fare riferimento alla cronologia. Abbiamo scoperto che se dovessimo investigare su un bug in un vecchio file / progetto con la cronologia non avremmo avuto alcun beneficio. Finché mantieni il vecchio repository disponibile per 6 mesi / un anno avrai il riferimento in questi casi.

Sul lato gestionale, è principalmente una questione di:

• supporto : la società rilascerà ancora il VCS in caso di problemi.
  È tristemente uno dei motivi principali per cui vengono ancora considerati prodotti obsoleti come ClearCase (ClearCase è dal 2003 un ... IBM prodotto)
• costo della licenza : anche se ci sono alternative gratuite, a volte "licenze di gruppo" per un VCS possono essere negoziate o effettivamente incluse in un contratto molto più ampio tra cui server, reti, supporto, ecc ... Una licenza globale per questo tipo di prodotto può costare molto meno del prezzo pubblico.

Dal lato del progetto, è anche una questione di:

• amministrazione : su quale server installerai un VCS (o molti VCS se stiamo parlando di Git, SVN e altri)? Con quale politica di backup? Quale DRP (Disastry Recovery Plan)?
• supporto locale : chi prenderà il supporto di livello 1? livello 2?
• conoscenza del mercato : sei sicuro di trovare abbastanza sviluppatori e / o amministratori con le giuste conoscenze per sfruttare questo VCS e tutte le sue funzionalità?

Gratuito o meno, ricorda che un software "gratuito" è gratuito come in "libertà di parola" (sei libero di scegliere e distribuire quello che vuoi), non come in "birra gratis" (costerà comunque molto denaro in server, backup, amministrazione, supporto, ...)

I criteri sopra menzionati sono un inizio per determinare che cosa conservare VCS, cosa abbandonare.
Ma in quest'ultimo caso, è necessario considerare:

• strategia di migrazione : puoi esportare / importare una cronologia del progetto da un VCS a un altro?
• strategia del bridge : ha senso avere una cronologia in due VCS diversi?
• obsolescenza del progetto : se un progetto è in stato di manutenzione / Fine vita, potrebbe essere preferibile supportare un vecchio VCS per un breve periodo.

Hai davvero bisogno di integrare diversi sistemi? Nel nostro team, ogni progetto vive nel proprio repository e le loro storie sono quindi indipendenti. Non abbiamo alcun problema qui a lavorare con alcuni progetti sotto sovversione e altri sotto mercuriali, anche se ci sono delle dipendenze tra loro.

Se scegli di migrare da un VCS a un altro, guarda gli strumenti di conversione disponibili. Non c'è, per la mia esperienza, nessun motivo tecnico per cancellare le storie dei progetti.

Modifica

Penso di aver capito qualcosa, che era implicito nella domanda e in altre risposte. È il fatto che VCS sono anche usati per gestire le dipendenze. So che è abbastanza comune usare funzioni VCS come svn:externals per integrare un repository (la dipendenza) con un altro.

Penso che la ragione (tecnica) per cui il nostro team non sente il bisogno di collegare (o integrare) i nostri 2 sistemi diversi è che abbiamo uno strumento separato per gestire le dipendenze. I nostri pronti contro termine non si conoscono.

Lotto di buone risposte. Un'altra cosa a cui pensare è non lasciare che i membri del team facciano a meno di pensare che cambiare il VC sia un grosso problema. Ci sarà una battuta d'arresto con la migrazione, una curva di apprendimento, ecc., Ma se hanno troppi problemi, devono mettere in discussione il loro livello di abilità e / o cooperazione.