Come creare e gestire in feature branch su SVN con TortoiseSVN.

1. Branching con TortoiseSVN
Gestione 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 dell’URL del
nuovo branch
 Modalità 3: fare lo SWITCH della working copy del trunk
all’URL 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 all’interno 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 concorrenti
TRUNK
NEW 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 revisions
Si usa quando si vogliono riportare le modifiche del trunk
su 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 l’URL 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 branch
Si usa quando si vogliono riportare le modifiche dei un
branch sul trunk
 Posizionarsi sulla working copy del trunk
 Attivare il menu TortoiseSVN > Merge
 Selezionare la seconda voce «Reintegrate a branch»
 In «From URL» selezionare l’URL 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