Nei capitoli precedenti abbiamo esaminato le operazioni più comuni nell'utilizzo di Subversion; queste conoscenze possono bastare per un utilizzo basilare e soddisfare la maggior parte delle esigenze. Ad esempio chi lavora da solo e usa il prodotto solo come archivio e storico delle modifiche, potrebbe anche non aver mai bisogno di utilizzare le funzionalità avanzate di Subversion.
Nelle prossime lezioni approfondiremo la gestione di diversi rami di uno stesso progetto, una caratteristica comune a tutti i software di controllo di versione.
Un ramo nasce semplicemente come copia del progetto principale; ne condivide la storia fino al momento della separazione, ma procede poi – temporaneamente o per sempre, a seconda delle esigenze, su un binario separato. I diversi rami rimangono comunque in qualche modo collegati, infatti è possibile trasportare le modifiche da un ramo all'altro o addirittura fondere completamente due o più rami.
I motivi che portano all'uso dei rami sono tipicamente due:
- La creazione di diverse versioni dello stesso progetto, da mantenere separate. Ad esempio, nel caso di questa guida, potremmo volerne realizzare una versione destinata al sistemista che si occupa di configurare e gestire il server e un'altra destinata al programmatore. Alcune parti saranno in comune; altre sarebbero presenti solo in uno dei due rami; altre ancora sarebbero presenti in entrambi, ma con un contenuto leggermente modificato. In questo caso dovremmo creare due rami separati, destinati a rimanere tali, trasportando dall'uno all'altro le modifiche che riguardano le parti comuni.
- La creazione di un ambiente di sviluppo temporaneo, destinato prima o poi a essere fuso con il ramo principale. Il caso tipico è lo sviluppo di nuove funzionalità in un programma: visto che di solito questa fase richiede un certo tempo, non si può pensare di lavorare a lungo sulla propria copia locale senza caricare sul server le modifiche, ma d'altro canto non si vogliono mischiare le modifiche “in corso” con la versione funzionante presente nell'albero principale – che deve rimanere disponibile per il debug quotidiano e per generare i rilasci. Si crea quindi un ramo secondario nel quale viene ospitata la versione di sviluppo. Quando questa versione sarà completa, i due rami saranno riuniti in uno solo.
Specialmente nel secondo caso, è importante tenere sincronizzati spesso i due rami. Se infatti questo non avviene, i due binari si allontanano sempre di più e quando sarà il momento di unirli avremo un numero ingestibile di conflitti. E oltre ai conflitti veri e propri (intesi come sovrapposizioni delle modifiche) è sempre possibile che ci siano altre modifiche, in punti diversi dei file, che in qualche modo ci coinvolgono e ci costringono ad adattare il nostro codice. In questo caso, il dialogo tra gli sviluppatori è fondamentale.