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

11

Le società acquisiscono altre società che utilizzano diversi sistemi di controllo della versione.

Esiste una saggezza comune su come integrare tali sistemi insieme, ad esempio utilizzando un bridge Subverson-GIT o addirittura decidendo di utilizzare solo uno strumento rispetto a un altro e come migrare tra i sistemi?

Le persone usano una serie di criteri per tale processo decisionale, ad esempio un equivalente del test "Joel" sullo sviluppo del software?

version-control migration

— therobyouknow
fonte

11

Per rispondere alla domanda sulla 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 lavorare da lì.

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

I file / progetti che vengono sviluppati attivamente genereranno presto una nuova storia. Quindi, quando è necessario scoprire perché è stata apportata una modifica, è probabile che la cronologia sia nell'archivio corrente in quanto sarà una modifica recente.

I file / progetti che erano stabili prima della migrazione (a parità di condizioni) dovrebbero rimanere stabili dopo la migrazione, quindi non sarà necessario fare riferimento alla cronologia. Abbiamo scoperto che se avessimo dovuto indagare su un bug in un file / progetto così vecchio con la cronologia non sarebbe stato di alcun beneficio. Finché manterrai il vecchio repository disponibile per 6 mesi / anno avrai il riferimento in questi casi.

— ChrisF
fonte

+1 punto giusto, migra solo ciò di cui hai bisogno, lascia le vecchie versioni nel repository precedente legacy. Non migrare per se stesso. Questo approccio è una variazione dell'approccio alla scelta tra organizzazione e ricerca. Se la ricerca può ottenere ciò che desideri rapidamente, ogni volta non è necessario organizzare ciò che cerchi.

— therobyouknow,

1

+1 IMO la migliore strategia. Continua a usarne solo uno, gli altri in sola lettura per ogni evenienza.

— user281377

1

+1: risposta più accurata sulla parte di migrazione.

— VonC,

1

+1: abbastanza difficile da capire il codice esistente e tanto meno le ultime tre versioni.

— JeffO,

1

Abbiamo convertito molti repository CVS in SVN usando il fantastico script cvs2svn, che ha funzionato davvero bene. Non ricordo mai nessuno che guardasse la storia al di là dei "recenti cambiamenti", quindi questo non valeva davvero lo spazio su disco. Se lo facessi di nuovo, taggerei semplicemente il repository CVS, farei il check-in su SVN come nuovo e quindi contrassegnerei il repository CVS come di sola lettura.

— JBR Wilkinson,

4

Dal punto di vista manageriale, si tratta principalmente di:

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

Dal punto di vista del progetto, si tratta anche 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 la giusta conoscenza impostata per sfruttare questo VCS e tutte le sue funzionalità?

Freeware o no, ricorda che un software "gratuito" è gratuito come in "libertà di parola" (sei libero di scegliere e distribuire quello che desideri), non come in "birra gratis" (costerà comunque un sacco di soldi nel server , backup, amministrazione, supporto, ...)

I criteri sopra menzionati sono un inizio per determinare cosa VCS mantenere, cosa abbandonare.
Ma in quest'ultimo caso, devi considerare:

strategia di migrazione : è possibile esportare / importare la cronologia di un progetto da un VCS a un altro?
strategia ponte : ha senso avere una storia in due diversi VCS?
obsolescenza del progetto : se un progetto è in stato di manutenzione / fine vita, potrebbe essere meglio supportare un vecchio VCS per un breve periodo.

— VonC
fonte

+1 buona risposta, i punti elenco evidenziano i criteri che sto cercando e anche le tue spiegazioni con loro aiutano. Darò agli altri una possibilità prima di accettare una risposta. Grazie.

— therobyouknow, il

1

Hai davvero bisogno di integrare sistemi diversi? Nel nostro team, ogni progetto vive nel proprio repository e le loro storie sono quindi indipendenti. Qui non abbiamo problemi a lavorare con alcuni progetti in sovversione e altri in fase mercuriale, anche se vi sono dipendenze tra di loro.

Se scegli di migrare da un VCS a un altro, guarda gli strumenti di conversione disponibili. Dalla mia esperienza, non vi è alcun motivo tecnico per abbandonare la storia dei progetti.

modificare

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

Penso che il motivo (tecnico) del nostro team non senta la necessità di collegare (o integrare) i nostri 2 sistemi diversi sia che abbiamo uno strumento separato per gestire le dipendenze. Il nostro repository non si conosce.

— barjak
fonte

Hai bisogno di integrare sistemi diversi? Sì, se il lavoro di una squadra viene utilizzato da un'altra squadra. L'integrazione può essere stretta o persa a seconda del livello di necessità e delle risorse di personale disponibili. No se i progetti sono completamente indipendenti. L'unica preoccupazione rimasta è supportare più di un sistema e se ciò è percepito come una cosa buona o cattiva. Bene se accettiamo di vivere in un mondo informatico variegato o male se pensiamo che dovremmo concentrarci e mostrare determinazione per se stessi, scegliendo uno strumento stesso che potrebbe essere eccessivamente solipstistico!

— therobyouknow,

PS. +1 Fortunato te, barjak, per essere in un'organizzazione che tollera un ambiente informatico vario.

— therobyouknow, il

0

Molte buone risposte. Un'altra cosa a cui pensare è di non lasciare che i membri del team pensino che cambiare 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.

— Jeffo
fonte

+1 Un realismo qui. Le persone hanno bisogno di mantenere il coraggio, essere coraggiose e procedere. I rischi devono essere ben definiti. Un apprendimento che sto vedendo e ascoltando dire altre persone sul mio posto di lavoro è che a volte non lavoriamo abbastanza duramente per ridurre l'incertezza / definire chiaramente i rischi / le contigenze prima di impegnarci. Sembrerebbe che ci sia un sacco di tempo per l'iterazione get-it-wrong / fix ma non abbastanza tempo per farlo bene la prima volta. La risoluzione dei problemi viene premiata e vista come attività in corso, anche se a volte non erano necessarie.

— therobyouknow,

1

Dipende dai VCS in questione e dalla buona riuscita della migrazione. Passare da Git o persino CVS a qualsiasi VCS bloccante sarà estremamente stonante.

— David Thornley,