P. 1
svn-book

svn-book

|Views: 23|Likes:
Published by Mohamad Efazati
svn book
svn book

More info:

Published by: Mohamad Efazati on Oct 17, 2010
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

09/08/2014

pdf

text

original

A feature branch is the sort of branch that's been the dominant example in this chapter (the
one you've been working on while Sally continues to work on /trunk). It's a temporary
branch created to work on a complex change without interfering with the stability of /
trunk. Unlike release branches (which may need to be supported forever), feature
branches are born, used for a while, merged back to the trunk, and then ultimately deleted.
They have a finite span of usefulness.

Again, project policies vary widely concerning exactly when it's appropriate to create a fea-
ture branch. Some projects never use feature branches at all: commits to /trunk are a
free-for-all. The advantage to this system is that it's simple—nobody needs to learn about
branching or merging. The disadvantage is that the trunk code is often unstable or unus-
able. Other projects use branches to an extreme: no change is ever committed to the trunk
directly. Even the most trivial changes are created on a short-lived branch, carefully re-
viewed, and merged to the trunk. Then the branch is deleted. This system guarantees an
exceptionally stable and usable trunk at all times, but at the cost of tremendous process
overhead.

Most projects take a middle-of-the-road approach. They commonly insist that /trunk
compile and pass regression tests at all times. A feature branch is required only when a
change requires a large number of destabilizing commits. A good rule of thumb is to ask
this question: if the developer worked for days in isolation and then committed the large
change all at once (so that /trunk were never destabilized), would it be too large a
change to review? If the answer to that question is “yes,” the change should be developed
on a feature branch. As the developer commits incremental changes to the branch, they
can be easily reviewed by peers.

Finally, there's the issue of how to best keep a feature branch in “sync” with the trunk as
work progresses. As we mentioned earlier, there's a great risk to working on a branch for
weeks or months; trunk changes may continue to pour in, to the point where the two lines
of development differ so greatly that it may become a nightmare trying to merge the branch
back to the trunk.

This situation is best avoided by regularly merging trunk changes to the branch. Make up a
policy: once a week, merge the last week's worth of trunk changes to the branch.

At some point, you'll be ready to merge the “synchronized” feature branch back to the
trunk. To do this, begin by doing a final merge of the latest trunk changes to the branch.
When that's done, the latest versions of branch and trunk will be absolutely identical except
for your branch changes. You would then merge back with the --reintegrate option:

$ cd trunk-working-copy

$ svn update
At revision 1910.

$ svn merge --reintegrate http://svn.example.com/repos/calc/branches/mybranch
--- Merging differences between repository URLs into '.':
U real.c
U integer.c

Branching and Merging

114

A newdirectory
A newdirectory/newfile
U .

Another way of thinking about this pattern is that your weekly sync of trunk to branch is
analogous to running svn update in a working copy, while the final merge step is analog-
ous to running svn commit from a working copy. After all, what else is a working copy but
a very shallow private branch? It's a branch that's capable of storing only one change at a
time.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->