1. Subversion User Training
Branching & Merging
Author: Polarion Software
Web:

2. Why do I need branches?
Merging with subversion
Different branching strategies
Dangerous merging
Do’s and dont‘s

3. Why do I need branches?

4. Why do I need branches? What is a branch? A branch is ... +
independent line of development, sharing a common history with other lines
a branch starts always a copy of a specific folder/file
branch +
svn cp
trunk
time

5. Why do I need branches? Who needs branches? 3 kinds of SVN users:
svn add/delete
svn checkout
svn status
svn commit
svn update
svn log
SVN !!
svn cp
svn switch
svn propset
svn propget
svn proplist
SVN
svn merge
svn mergeinfo
No need for branches (yet!)
branching and merging support needed
branching strategy needed

6. Why do I need branches? code stability release preparation
traceability (integration of change/defect management)
increasing complexity
parallel development
research
support different platforms

7. When not to use branches?
Why do I need branches?
When not to use branches?
Never use branches for:
multiple project support of your software product
will lead to maintenance hell!

8. Merging with subversion

9. Merging with subversion
a merge will always apply a “patch” to a workingcopy
a patch is always a difference between two versions/trees
in this sample below we create the patch between revision 4 and 7 6 7 6 7 4
branch
branch 4
merge
8=6+7 2 3 5 8 5 8
trunk (wc)‏

10. Merging with subversion Reintegrate branch

11. Merging with subversion Reintegrate branch
reintegrate branch will keep track of all previous merged revisions and will not try to merge them back
conditions apply:
no switched working copy
If revisions from trunk have been merged to the branch If so, make sure we've merged contiguously (so example below will only work if either no revision, 5 or both 5 and 7 have been merged to the branch)‏
featurebranch 6 9 4 6 8 9 10 8
10
branch
11=6+9 4
merge 3
trunk (wc)‏ 11 5 7 5 7

12. Merging with subversion Cherry picking
choosing specific revisions to merge
no need for continous range
mergetracking avoids double merges
you need interactive conflict resolution, if first rev. causes a conflict 6 8 9
10
featurebranch 4 6 8 9 10
branch
11=8+10 4
merge 3
trunk (wc)‏ 11 5 7 5 7

13. + + Merging with subversion ignore ancestry X
ancestry means two object share same history
as SVN supports deletion of files, filenames are no indication for ancestry
on merge two files which share same name, but are not ancestors files will not be merged, but replaced
Vendor branches may depend on „ignore ancestry“ + A A X 3 5 7
replaced! + A A 1 2 4 6 8 9

14. Merging with subversion ignore white spaces
SVN will not merge changes in amount of whitespaces (>>)
def increment(x):
>> if type(x)==type(1):
>> >> x+=1;
>> >> if x>10:
>> >> >> print „max reached!“
>> >> >> x=10
>> return x
def increment(x):
>> x+=1;
>> if (x>10):
>> >> print „max reached!“
>> >> x=10
>> return x
def increment(x):
>> if type(x)==type(1):
>> >> x+=1;
>> >> if x>10:
>> >> >> print „max reached!“
>> >> >> x=10
>> return x

15. Merging with subversion Tree conflicts
SVN cannot rename files/folder
SVN will delete old file and add new file with deleted file as ancestor
Prior to svn 1.6 merging was difficult and dangerous, if renames occurred on branch
avoid renaming on branches to avoid tree conflicts

16. Merging with subversion Tree conflicts 1/3
Demonstration of a tree conflicts :
create a project (trunk) with 1 file named „readme.txt“:
first line.
This is initial some Text
Alice: there is a last line but not here.
bob added a new line here..
Alice: this is the last line..
create a branch called „dangerous_merge“
check out branch and append a single line to readme.txt:
appending a new line at the end in branch
commit changes to branch

17. What do you expect? Merging with subversion Tree conflicts 2/3
in trunk: insert a new 1st line of text to readme.txt:
*** This is the line added in trunk ***
commit these changes as well.
in branch: rename readme.txt to readme2.txt and commit
in trunk: merge last 2 revisions from branch into trunk
What do you expect?

18. Why? Merging with subversion Tree conflicts 3/3
In SVN 1.6 you get a „tree conflict,
prior to SVN 1.6 the content of „readme2.txt“ was:
first line.
This is initial some Text
Alice: there is a last line but not here.
bob added a new line here..
Alice: this is the last line..
appending a new line at the end in branch
Changes from trunk just vanished!
Why?

19. Merging with subversion Tree conflicts
readme.txt:
*** This is the line added in trunk ***
merge
trunk
branch
readme.txt:
appending a new line at the end in branch
copy readme.txt readme2.txt
delete readme.txt

20. Different branching strategies

21. Different branching strategies unstable vs. stable trunk
2 different kind of branching strategies:
unstable trunk (late branching)
stable trunk (early branching)

22. Different branching strategies unstable trunk
you always commit into trunk.
sometimes developer branch to develop features
trunk shows always the current development state
Releases:
maintain a branch
feature freeze on this branch
fix bugs
prepare release
Feature X
Bugfix A
Bugfix A
Release 1.1
trunk
Release 1.0

23. Different branching strategies unstable trunk
PRO
easy to understand
easy to maintain
good overview of development status
very few merges needed
CON
no traceability of codeartifacts
no removal of features
risky parallel development
broken builds
user will prevent commits
complex defect analysis
more conflicts
seldom updates

24. Different branching strategies stable trunk
you never commit directly to trunk
you always merge from branches to trunk
you need at least one specific branch strategy
Releases:
releases are always revisions on trunk
Feature X
Bugfix A
trunk
Release 1.0
Release 1.1

25. Different branching strategies stable trunk
PRO
feature is a single commit on trunk
easy removal of features
trunk always builds
user can work on parallel tasks
enhanced traceability
conflicts only while integration
base for most branching strategies
CON
complex concept
maintainer needed
overkill for small projects(?)
difficult to get overview
good versioning skills needed

26. Different branching strategies
Feature (Task) branches
Developer (Private) branches
Bugfix (Task) branches
Release branches
Platform branches
Experimental branch
Vendor branches*
*) Vendor branches are not a branching strategy,, but a development tool

27. Different branching strategies Feature branch
implementation of a single feature
single feature will be inserted into project exactly in 1 commit (rev. 8)
undoing feature is easy
Feature branch 3 5 7 1 2 4 6 8 9
trunk

28. Different branching strategies Developer branches
each developer maintain his own branch
tasks will be merged back by project lead developer (rev. 8)
very stable trunk (is only writeable by project lead)
developer must maintain branch by merging new revisions (rev. 4)(notifications!)
Developer branch 3 5 7
merge 1 2 4 6 8 9
trunk

29. Different branching strategies Bugfix branches
implementation of a single bugfix
bugfix will be inserted into project exactly in 1 commit (rev 8)
undoing feature is easy
similar (equal) to feature branches, but usually smaller
bugfix branch 3 5 7 1 2 4 6 8 9
trunk

30. Different branching strategies Release branch
Release branch ends on release
Code stabilization
Bugfixes on release branch will be merged back to trunk
No new features on release branch
Release branch
Release 1.0 3 5 7
Bugfix 1 2 4 6 8 9
trunk

31. Different branching strategies Platform branches
Platform branches are living „forever“
You will alway have at least 2 platform branches
branches are usually not very active, just receiving merges from trunk
Platform branch WIN 4 7
Platform branch UX 3 6 1 2 5 8 9
trunk

32. X never! Different branching strategies Experimental branch
Experimental branches are for testing different scenarios
similar to developer branches without merge back
you should not merge back into trunk!
merge from trunk to keep experiment up-to-date
should be deleted after getting results
Experimental branch 3 5 7
X never! 1 2 4 6 8 9
trunk

33. + + Different branching strategies Vendor branches
Vendor branches are modified 3rd party code
you keep a modified version of 3rd party code in /current/ folder (rev. 5)
on new releases the changes between releases will be merged into trunk (rev. 7) +
importing Vendor branch V2.0 +
importing Vendor branch V1.0 2
merge delta V2.0 – V1.0
Vendor branch current (modified) 3 5 7 1 4 6 8
trunk

34. Summary & Appendix

35. Do’s and dont‘s Summary & Appendix Do’s
define your branching strategy before start developing
key part of a branching strategy should be a naming convention for branches
describe integration with bugtracking / CM / PM Tools
try to think of a merging concept, not a branching strategy
define most important parts of merging process: TESTS
unit test
integration test
system test
change your branching strategy as soon as you experience problems
merge only root of branch, do not merge subdirectories separately
merge only to working copies without local modifications
be careful with renames on branches

36. Do’s and dont‘s Summary & Appendix avoid
Merge Paranoia — avoiding merging at all
Merge Mania — spending too much time merging instead of developing
Big Bang Merge — deferring branch merging and attempting to merge all branches
Never-Ending Merge — continuous merging activity
Wrong-Way Merge — merging a software asset version with an earlier version.
Branch Mania — creating many too branches
Cascading Branches — branching but never merging back
Mysterious Branches — branching for no apparent reason.
Temporary Branches — branching for changing reasons, so the branch becomes a permanent temporary workspace.
Volatile Branches — branching with unstable software assets shared by other branches
Development Freeze — stopping all development activities while merging
Berlin Wall — using branches to divide the development team instead of work

37. Summary & Appendix
Polarion TRACK & WIKI
Get your free copy today!

38. Summary & Appendix Online resources http://subtrain.tigris.org

39. Any Questions?

40. Please visit our website for more information
Thank You!