2009-02-12 23 views
16

Stiamo prendendo in considerazione il passaggio da ClearCase a Subversion. Il progetto è lì da un po '(7 anni) e ci sono tre versioni "principali" (rami) che supportiamo attivamente, oltre a alcune correzioni occasionali nelle versioni precedenti. Il progetto è abbastanza grande - circa 2 mln di linee di codice java.Qual è la strategia migliore durante la migrazione da ClearCase a SVN?

Sono curioso di sapere se c'è qualcuno che ha fatto una migrazione simile.

  • SVN sarà in grado di gestire un progetto così ampio?
  • Ha senso migrare tutte le versioni/rami storici? Gli strumenti possono farlo in modo selettivo?
  • Quanto tempo impiegherà il processo di migrazione per un progetto di questo tipo e qual è il modo efficace di lavorare, quindi la migrazione è in corso?
+0

I seconda domanda. ;-) –

+0

domanda breve. Finestre? – Avram

risposta

9

Per aver fatto diverse migrazioni di questo tipo, direi che:

  • non è necessario importare tutta la storia delle versioni ClearCase in SVN. Il più delle volte (per la mia esperienza), sono necessarie solo le versioni etichettate (quella che viene applicata in modo coerente su tutti i file di un determinato set), a meno che non si abbia realmente bisogno di una revisione della storia a grana fine.

  • è necessario pensare a riorganizzazione durante una migrazione:?? Che cosa si importa, ciò che si lascia, e si desidera che il contenuto di SVN riflettere esattamente la struttura dei file memorizzati nella il VOB ClearCase? A volte tali migrazioni sono l'occasione per ripensare alcuni di questi file di organizzazione (di solito attraverso semplici regole di ridenominazione per certe directory).

  • la migrazione è più rapido nel modo ClearCase 2 SVN, dal momento che SVN è repository-centrica e commettono una serie di file, mentre ClearCase è il file-centrica e si impegna di file per file (molto sloooower)

  • se il set di file da importare è chiaramente identificato, il processo di migrazione può essere ripetuto più volte, il che significa che è possibile continuare a lavorare all'interno di ClearCase mentre è in corso la prima (grande) importazione, quindi inserire una Baseline (etichetta UCM) sul codice e reimportare solo il delta, terminando in modo efficace il processo di migrazione.

1
  1. Sì, Subversion può gestire progetti molto grandi. Ad esempio, tutti gli Apache projects si trovano in un unico repository Subversion con i sottoprogetti che sono sottocartelle semplici
  2. Se ha senso convertire tutta la cronologia, è necessario decidere autonomamente. Ma ci sono molti strumenti disponibili. Un buon post sul blog può essere trovato here.
  3. Non so per quanto tempo ci vorrà una tale conversione. Ma puoi provare prima con un piccolo sottoinsieme e misurare il tempo.
+0

Contrariamente a quello che pensi, Apache non è un progetto molto grande, non è nemmeno un grande progetto. Ha solo circa 30 contributori o così. È un progetto di medie dimensioni. SVN non è realmente in grado di gestire grandi progetti. La dimensione della base di codice non è in realtà un fattore decisivo tanto quanto il numero di persone che hanno bisogno di collaborare e la quantità di interazione, ramificazione e fusione. –

+0

Si prega di dare un'occhiata al repository Apache (http://svn.apache.org/repos/asf/) prima di fare false assunzioni sulla dimensione del progetto. Il repository non ospita solo il progetto server Web Apache ma * tutti * i progetti Apache, insieme a centinaia di committer. – Stefan

+0

La dimensione del codice base di solito non è un problema per qualsiasi sistema di controllo sorgente. Ad eccezione forse di ClearCase, che nelle versioni precedenti aveva un limite di 16 milioni di oggetti per vob, il che significava qualsiasi versione o etichetta applicata a qualsiasi versione. Avevi bisogno di dozzine di vob per progetti di grandi dimensioni o iniziare a cancellare vecchie versioni. Non che sia rilevante per questa particolare domanda, ma ciò che dici di Apache continua a non renderlo un progetto di grandi dimensioni, ma solo un codice di grandi dimensioni. SVN è perfettamente in grado di gestire codebase di grandi dimensioni, solo un numero non molto elevato di contributori e un complesso processo di sviluppo. –

5

Prima alcune risorse:

  1. Clearvision CC2SVN Tool
  2. SVN Importer by Polarion
  3. Article and resources on CollabNet

La dimensione del repository attuale, numero di file o le loro dimensioni non sono un fattore limitante per SVN. Il numero di sviluppatori, la concorrenza di cambiamenti, la complessità del processo di integrazione e di rilascio, hanno bisogno per la fusione e la directory delle versioni (refactoring) potrebbe creare problemi per un grande progetto. Se il progetto è solo grande, ma è abbastanza stabile, con basso numero di sviluppatori, piccolo numero di sportelli e senza bisogno di backport di tonnellate di correzioni per diversi versioni precedenti, SVN dovrebbe fare bene per te.

ho scritto uno strumento di migrazione personalizzato portare dati da ClearCase e non è un compito facile. Ogni due sistemi hanno diversi modelli di dati e operazioni sui dati. Non suggerirei di provare a scrivere uno strumento di migrazione personalizzato, perché è molto difficile ottenere dati da ClearCase in modo significativo. Per i dettagli sui limiti delle soluzioni commerciali suggerirei di contattare i fornitori di soluzioni collegate in risorse.

io personalmente cercare di portare più di quanti più dati possibile, ma è necessario essere consapevoli dei limiti di SVN rispetto a ClearCase. Qualsiasi cronologia delle versioni di directory (refactoring) verrà probabilmente persa durante questa migrazione. SVN non supporta i rami sparsi come ClearCase, che potrebbero gonfiare le dimensioni del tuo repository SVN nel caso in cui hai utilizzato i rami delle attività. In tal caso, probabilmente ti vuoi limitare solo alle filiali di sistema. I file in ClearCase hanno una singola struttura di diramazione, mentre SVN ha una sorta di diramazione per prodotto, il che comporterà molte traduzioni di diramazioni nel processo. Limitando te stesso ai rami del sistema e magari solo la versione etichettata su quei rami per etichette completamente integrate nella serie, potresti risparmiare un sacco di problemi. Nel caso in cui la tua squadra stia utilizzando UCM, puoi quasi dimenticare tutti i metadati UCM. Non si tradurranno in SVN.

Il lasso di tempo dipende in gran parte degli strumenti utilizzati. Per un progetto importante come quello che hai potrebbe essere anche settimane. Il database ClearCase ha per qualche strano motivo un sacco di blocco anche sulle operazioni di lettura e c'è una tabella centrale di tutto ciò che crea un sacco di problemi nell'accesso su larga scala come potrebbe causare la migrazione. La prima volta che ho eseguito il mio strumento sul prodotto po 'più grande della tua, abbiamo stimato che sarebbe una durata di 3 anni, dopo molte ottimizzazione, parallelizzazione e la migrazione incrementale è ridotto a circa una settimana. Ma aspettati che, a seconda di quanto bene lo strumento è fatto, ci potrebbe essere molta varianza nel tempo necessario. Anche se dal momento che si esegue la migrazione in SVN e si ignorerà gran parte della cronologia e dei metadati di ClearCase, la migrazione dovrebbe essere molto più rapida.

ClearVision, accenna alle sue pagine che il suo strumento CC2SVN può creare un ponte tra i due prodotti. Anche se non ho usato questo strumento, se funziona come presumo, ti permetterebbe di sincronizzare i 2 repository dopo un po 'di elaborazione, il che ti permetterebbe un passaggio al fine settimana, con zero tempi di sviluppo. Se ciò non è possibile, provare a chiedere un'alternativa come la migrazione incrementale, dove prima si esegue la migrazione fino a una certa data, quindi si esegue la migrazione di una parte più piccola di dati modificati da quella data.

Parte molto importante del processo è la fase di post-migrazione. Per favore non scontare il mal di testa che lo switch porterà ai tuoi sviluppatori. Non devi sottovalutare la necessità di formazione e documentazione chiara. Avrai anche bisogno di un team di supporto addestrato nel tuo dipartimento di ingegneria del software in grado di gestire entrambi i sistemi SCM e di spiegare agli sviluppatori come fare le cose a cui erano abituati nel nuovo sistema.Questo è in realtà un punto che potrebbe spezzarti il ​​collo durante la migrazione. Gli sviluppatori si oppongono a qualsiasi cambiamento e qualunque sia il vantaggio che SVN apporta al progetto, è essenzialmente un sistema molto inferiore. ClearCase offre ai tuoi sviluppatori tanta flessibilità che non avranno mai con SVN e, a meno che non li porti a bordo nelle prime fasi del processo, puoi perderli o peggio, far annullare l'intera migrazione, dichiarare un disastro e perdere il tuo lavoro.

1

Un'altra opzione è Migrate2SVN. Lo sviluppatore (Clearvision) ha appena rilasciato la versione 2.0 e sembra includere molti, MOLTI miglioramenti rispetto al software Polarion e altri metodi citati sopra.

Problemi correlati