1. Branching con TortoiseSVNGestione di un feature branch con TortoiseSVN Andrea Colleoni - 2013

2. Branching e tagging La creazione di un branch o di un tag in SVN consiste nella creazione di un collegamento ad una certa revisione di una certa posizione del repository Branches, Tags e Trunk sono distinzioni convenzionali; non vi alcuna differenza strutturale tra questi tipi di location Un branch concepito per registrare dei cambiamenti e a dare origine a nuove revisioni, un tag no Dal momento in cui viene creato un branch possibile gestire una working copy di quel branch e registrarne le revisioni Quando una working copy punta ad un branch, ogni commit verr attribuito a quel branch Non vi limite al numero di branch e tag che si possono creare in un repository SVN

3. Creazione di un branch Individuare la root directory della propria working copy Dal menu TortoiseSVN, selezionare la voce Branch/tag Digitare il nuovo URL che diventer il nome del nuovo branch, posizionandolo in /branches Digitare un messaggio esplicativo e premere OK

4. Uso del branch Modalit 1: contestualmente alla creazione possibile fare lo SWITCH della working copy al nuovo URL Modalit 2: fare un CHECKOUT dellURL del nuovo branch Modalit 3: fare lo SWITCH della working copy del trunk allURL del nuovo branch Da questo momento in poi la working copy punter al nuovo branch La modalit suggerita la 2

5. Modifiche sul branch Effettuare modifiche su una working copy che punta al branch del tutto simile ad effettuarle su qualsiasi altra working copy Facendo un SVN COMMIT la revisione verr registrata nel log del branch Esaminando il log di un repository con pi branches, si noteranno dei salti nel numero di revisione; questo perch il numero di revisione unico allinterno del repository Per poter modificare il trunk oltre che il branch, necessario avere anche la working copy del trunk (usando la modalit 2 indicata precedentemente)

6. Modifiche concorrenti Avendo due working copy possibile effettuare due set diversi di modifiche, che verranno registrati in gruppi di revisioni differenti La revisione 4 crea il branch new feature ed ottenuta come copy della revisione 3 del trunk

7. Esempio: Revisioni concorrentiTRUNKNEW FEATURE La revisione 5 contiene il trunk modificato La revisione 6 contiene il branch modificato

8. Merge Le modifiche sul trunk vanno periodicamente riportate sui feature branch per evitare regressioni; per ottenere tale risultato, necessario usare il MERGE Tecnicamente le modifiche del trunk devono essere portate nella working copy del branch e poi committate sul branch; opportuno che ci avvenga in una transazione isolata rispetto ad altre modifiche Le annotazioni di SVN terranno memoria di quali revisioni di un ramo di un repository sono state riportate su un altro ramo del repository pertanto possibile rimanere fuori dal trunk anche per lungo tempo a patto di fare frequenti merge

9. Esempio: Merge a range of revisionsSi usa quando si vogliono riportare le modifiche del trunksu un branch Posizionarsi sulla working copy del branch Attivare il menu TortoiseSVN > Merge Selezionare la prima voce Merge a range of revisions In URL to merge from selezionare lURL del trunk e premere OK Nella schermata successiva, lasciare le impostazioni di default e premere Merge SVN applicher alla working copy del branch le revisioni del trunk non ancora applicate; la working copy risulter localmente modificata Effettuare un COMMIT del branch

10. Esempio: Reintegrate a branchSi usa quando si vogliono riportare le modifiche dei unbranch sul trunk Posizionarsi sulla working copy del trunk Attivare il menu TortoiseSVN > Merge Selezionare la seconda voce Reintegrate a branch In From URL selezionare lURL del branch e premere OK Nella schermata successiva, lasciare le impostazioni di default e premere Merge SVN applicher alla working copy del trunk le revisioni del branch senza riapplicare quelle gi apportate del trunk; la working copy risulter localmente modificata Effettuare un COMMIT del trunk

11. Best Practices Appena prima del reintegro di un branch necessario fare un merge delle revisioni del trunk sul branch da reintegrare Ogni giorno in cui si sviluppa su un branch, necessario fare un merge delle revisioni del trunk prima della fine della giornata per poter verificare eventuali conflitti e poi fare il commit sul proprio branch Quando un applicativo in produzione, il trunk non deve essere utilizzato per altro se non per il reintegro dei branch Ogni versione deve avere un branch Una volta messo in produzione un branch, il branch va reintegrato nel trunk, eliminato (in modo che da quella revisione in poi non venga pi mostrato) e il trunk taggato In questo modo ogni branch contiene tutte e sole le revisioni di una versione