The end result? The code in trunk is
broken. This is a situation we should strive to avoid??”ideally the code in trunk
should always work (undiscovered/unresolved bugs not withstanding).
So how do we develop things and get the benefits of Subversion if we can't check in
incomplete code? The answer is by using branches.
Chapter 6
[ 69 ]
When to check in?
This is purely a personal preference, but most will say that we should
only check in code that works. This can result in large gaps between
checkins, so we can counter that by breaking large changes into smaller
ones. This is not a hard and fast rule though, so be prepared to adapt
when required.
A branch is quite simply a copy of a folder in the repository. We create a branch
for the feature or bug we are working on, checking in as we go. Once we have
completed that section we will then merge our changes back into the trunk. There is
a caveat though??”our branch will be based on a moment in time, and the trunk may
change between the creation of our branch and when we merge our changes back in.
We need to take responsibility for ensuring our changes merge cleanly with other
changes that may have been made.
Creating a branch is quite simple, but we need to make the changes in the repository
rather than our working copy.
Pages:
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97