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