Come creare e gestire in feature branch su SVN con TortoiseSVN.
Transcript of Branching con TortoiseSVN
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