This document discusses different models for branching in concurrent software development using Subversion. It begins by defining branching and concurrent development. It then outlines different development models including "branch nothing," "branch everything," and "branch big things." It discusses when branching is appropriate and inappropriate. It also covers identifying, deleting, and finding deleted branches. The presentation concludes by emphasizing the importance of practice, policies and procedures, training, and revising policies for effective branching and merging.

1. Branching Options for
Development
Presenter
We will begin
in a few moments
Michael Lester
Wandisco
Director of Training

2. Branching Options for
Development

3. Outline
 Definition of concurrent development
 What is a branch
 Different development models
 What triggers a branch
 Branching Demonstration
 Communication for branching and
merging
 Conclusions
3

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

5. Non-Concurrent Development
33 34 43 51
Definition
The easiest type of development.
One person projects.
5

6. Concurrent Development
Branching
edit Simultaneous
Development
Definition
When the same code/project has multiple
developers working at the same time.
6

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

8. 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
8

9. Branching from working copy
9

10. Branching from the repository
10

11. Different Development Models
Branch nothing
Branch everything
Branch big things
11

12. “Branch nothing” development model
Payroll application
12 13 14 15
Trunk
edit
Sometimes a checkout/commit cycle does not
involve concurrent development
12

13. “Branch nothing” development model
Payroll application Tuesday
edit
12 13 14 15 16
Trunk Monday
edit
Wednesday
Sometimes a checkout/commit cycle does
involve concurrent development
13

14. “Branch nothing” development model
Payroll application 1st edit
14 15 16
Trunk
update
Before the second
2nd edit
developer can
commit, an update
needs to happen update
edit
14

15. Update issues
15
Extra step may introduce
• New bugs
update
• Unclear code
• Non-compilable
• Non-testable 2nd edit
• Update hesitation
update
edit
15

16. Update issues
15 18 23
This can be a real update update update
issue if lots of people
are working on the
2nd edit 3rd edit 4th edit
same files
update update update
edit edit edit
Design issues may make this a problem.
16

17. Update issues
What may happen
1. Users stop doing updates
2. Users start doing updates badly
17

18. Bug fix branch – merge or not decision
Payroll application
Trunk
Merge bugfix
back to trunk
Rel 1.0 No Changes
Rel 1.0 Bug Fix
18

19. The end of a bugfix
Payroll application
Rel 1.0 No Changes
Rel 1.0 Bug Fix
Rel 1.0 1 No Changes
19

20. More bugfixes
Payroll application
tags/ Rel 1.0 No Changes
branches/
Rel 1.0 Bug Fix
tags/ Rel 1.0 1 No Changes
tags/ Rel 1.0 2 No Changes
20

21. Release patches (bug-fix) – When to merge
Payroll application
Rel 1.0 Bug Fix
Trunk
This could involve all
changes to “Rel 1.0 Bug Fix”
21

22. Release patches (bug-fix) – When to merge
BankDocSystem
Rel 1.0 Bug Fix
Trunk
Or “cherry pick” specific
changes in “Rel 1.0 Bug Fix”
22

23. Release patches (bug-fix) – When to merge
BankDocSystem
Rel 1.0 Bug Fix
30 31
Trunk
Rev 31
Not needed in trunk
Or “cherry pick” specific
changes in “Rel 1.0 Bug Fix”
23

24. Bug fix merging notification – no automation
Trunk
Rel 1.0 Bug Fix
 Project management meetings
 Email
 Face-to-face
24

25. Merging notification – using SVN properties
1. Set property
2. Hook script emails correct developer
3. Hook script updates project management system
4. Changes property to “emailSent”
25

26. “Branch everything” development model
All developers work on
a branch related to a task
A bug An enhancement
When bugs /
enhancements are
finished, they are
merged into the trunk
26

27. “Branch everything” development model
Advantages
• All work isolated
• All work scheduled
• All work branched from stable trunk revision
• Small independent merges
Disadvantages
• Lots of branches
• Lots of merges
• Large overhead for some 1 character fixes
27

28. “Branch big things” development model
All tasks categorized
Classification is done
by project leaders or in
A branch team meetings.
Trunk
contains a group
development for
of related tasks
small things
or enhancements Criteria
• Scope
• Interactions of
bugs/enhancements
• Need for testing
• Time considerations
28

29. “Branch big things” development model
All tasks categorized
A branch contains
a group of related
tasks or
enhancements
When development
branches are finished,
they are merged into
the trunk
29

30. “Branch big things” development model
All tasks categorized
Trunk
12 13 14 15 development
for small things
Trunk
edit
Small development
needs should be quick,
relatively non-tested,
and usually done by
one person.
30

31. 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
31

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

33. 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
33

34. 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
34

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

36. Identifying Branches in Subversion
36

37. Identifying Branches in Subversion
Remember, you can always see
the svn:mergeinfo property
37

38. 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.
38

39. Finding Deleted Branches
Make it easy to find
deleted branches.
Use LOG messages
Move deleted branches
to a “Deleted” folder.
39

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

41. Promotions and resources
 Free MultiSite Evaluation for
Enterprises
o Free for 7 days
o No Risk
o $12K value
 10% Off SmartSVN Professional
 w/Discount Code
“SmartUpgrade10”
To speak to a global software development specialist: Stay connected:
sales@wandisco.com
@WANdisco
925.380.1728
Other questions?
info@wandisco.com linkedin.com/company/wandisco
925.380.1728
Copyright © 2010 WANdisco, Inc. All rights reserved.

42. Feb 28th
Getting Info
Out of Subversion
Presenter
March 14 th
Michael Lester
Advanced
Wandisco
Director of Training
Branching and
Merging
Copyright © 2012 WANdisco All rights reserved. 42