The document outlines the advanced techniques of branching and merging in concurrent development using Subversion, highlighting key definitions and processes involved in version control. It discusses when to branch, types of merges, and provides demonstrations along with tools to effectively manage code changes. The conclusion emphasizes the importance of practice, policy integration, and staff training in utilizing these techniques effectively.

1. Advanced Branching and
Merging Presenter
We will begin
in a few moments
Michael Lester
Wandisco
Director of Training

2. Advanced Branching and
Merging

3. Outline
 Definition of concurrent
development
 What is a branch
 What triggers a branch
 Not all branches require a merge
 Branching Demonstration
 Types of Merges
 How to do a merge
 Merge info
 Merging Demonstration
 Conclusions
3

4. This training is done with the latest
TortoiseSVN Version
http://www.wandisco.com/subversion/download

5. Concurrent Development
Definition
When the same code/project has multiple
developers working at the same time.
5

6. Concurrent Development
Subversion tools that support concurrent development
Author identification
Difference reporting
Branching
Merging
Hook scripts
6

7. Who changed / created / deleted what
7

8. Who changed / created / deleted what
Author information is available
through svnlook command
svnlook author -r 40 /var/svn/repos
And statistics
8

9. What is a Branch
The basic concept of a branch:
A line of development that exists
independently of another line
A branch always begins life as a copy of something,
and moves on from there, generating its own history.
3rd branch
1st branch
Original line of development
2nd branch
9

10. Reasons for Branching
• Releasing patches for systems
already in production.
• Preparing interim releases for
testing and user evaluation.
• Working on more than one major
version of the same code-base.
• Major changes require independent
development
10

11. Release patches (bug-fix)
Payroll application Rel 1.0
Trunk
Rel 1.0
Trunk
11

12. When to branch
• Concurrent development
• To isolate development
• To create tag projects
• Keep track of released code
• Custom branch
• Limited use
• To test unapproved changes
12

13. When NOT to branch
• Small changes
• From “TAGS” folder
13

14. Branching from working copy
14

15. Branching from the TAGS folder
Pros and Cons
There is a bug in Rel 1.0
What do you do?
1. Create a bug fix branch
1. Create a bug fix branch
2. Fix the bug
3. Create another “release”
tags folder branch
Check
out
Commit Edit
Update
15

16. Extending the TAGS folder
Pros and Cons
There is a bug in Rel 1.0
What do you do?
1. Checkout and Commit
to the Rel1.0 branch
Check
out
Commit Edit
Update
16

17. How do you keep track of
“What is the actual release”
17

18. Identifying Branches in Subversion
18

19. Deleting Branches
Remember:
The directory (project) can
always be recovered, but will
not display in the list
command unless a specific
revision (53) is specified.
19

20. Merging in action
Bug fix / concurrent development
20

21. Merging in action
one
two
Now the branch three
four
changes 5
one six
two Seven
three Eight
four
five
six
Seven one
eight twotwo
While the trunk three
four
changes five
six
Seven7
eight
21

22. Merging in action – modification occurs
After both commits
mike-bigfix-01172011
Trunk
22

23. Merging in action
You always start
from a working
folder
mike-bigfix-01172011
23

24. Merging in action – changes are made
one
twotwo
three
four
5
six
Seven7
eight
24

25. Merging in action – Commit to trunk
25

26. Merging in action – mergeinfo
The property svn:mergeinfo
is added automatically
26

27. Merging in action
The revision numbers 9 – 11 are the
starting and ending changes in the branch
27

28. Merge information
You can view the branch
information graphically
28

29. Merging in action – collision ahead
one
two22two
Now the branch three
four
changes 5
one six
two Seven
three Eight
four
five
six
Seven one
eight twotwo
While the trunk three
four
changes five
six
Seven7
eight
29

30. Merging in action
30

31. Merging in action
31

32. Merging in action – Resolve the conflict
Before you canyou a commit to do a
Remember – do still have you
must tell Subversion that the
commit to update the repository
conflicts have been resolved
32

33. Special merging situations – no change in trunk
After branch changes
bigfix-20311
11 12 13 14
7 8 9
Trunk
Merge like normal
svn:mergeinfo /payroll/bugfix-20311:11-14
Check out have to merge ? version
Do I the trunk HEAD
33

34. Using the hidden menu to merge
Shift/right click
34

35. Include merged revisions in Log Messages
35

36. Command line mergeinfo command
C:sourcenewFeature>svn mergeinfo c:sourcepayroll
 --show-revs merged
r15
r18
C:sourcenewFeature>svn mergeinfo c:sourcepayroll
 --show-revs eligible
r21
This can be used to show what has
been merged and what could be merged
36

37. Cherrypicking
This refers to choosing one
specific changeset from a
branch and replicating it to This fixed a
bug
another. reproducable
in the trunk This added a
new feature
for a unique
customer
Custom Branch
TRUNK
37

38. Cherrypicking
How does the other
branch find out about I It wasalogged as
fixed bug in my
the useful code? custom project
bug fix 1655.
Something about
that probably
exists in thesort”.
“customer trunk.
38

39. Another reason for Log Messages
How does the other
branch find out about
the useful code?
39

40. Searching for log messages
40

41. Merge from log messages
41

42. Conclusions
1. Practice
2. Practice
3. Add branching and merging to
“Policies & Procedures”
4. Train staff
5. Revise your policies &
Procedures
42

43. April 4th
Subversion
Administration
Presenter
Michael Lester
April 18th
Wandisco
Director of Training
Introduction
to SmartSVN
Copyright © 2013 WANdisco.com All rights reserved. 43