There are many different uses for branching and svn merge, and this section describes the most common.
Most software has a typical lifecycle: code, test, release, repeat. There are two problems with this process. First, developers need to keep writing new features while quality-assurance teams take time to test supposedly stable versions of the software. New work cannot halt while the software is tested. Second, the team almost always needs to support older, released versions of software; if a bug is discovered in the latest code, it most likely exists in released versions as well, and customers will want to get that bugfix without having to wait for a major new release.
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
/trunk. Unlike release
branches (which may need to be supported forever), feature
branches are born, used for a while, merged back to the trunk,
then ultimately deleted. They have a finite span of
Again, project policies vary widely concerning exactly
when it's appropriate to create a feature 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 unusable. 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 reviewed, 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
only required 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,” then the change should be
developed on a feature branch. As the developer commits
incremental changes to the branch, they can be easily reviewed
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
$ 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 A newdirectory A newdirectory/newfile U . …
可以用另一种考虑这种模式，你每周按时同步分支到主干，类似于在工作拷贝执行svn update的命令，最终的合并操作类似于在工作拷贝运行svn commit，毕竟，工作拷贝不就是一个非常浅的分支吗？只是它一次只可以保存一个修改。