302 | Chapter 10: Large Projects
- When creating a release for public consumption, there is often a period of test-
ing and evaluation. If the entire development team were frozen during this test
period, it would be very hard to get anything done. - A team may offer support for multiple versions of the software at the same time,
in effect making public their branching system. Bugfixes and occasionally fea-
tures must be backported to old releases of the software.
Most version control systems offer flexible branching and merging support. A branch
is an independent line of development that can be developed on its own and merged
back into the trunk.
Subversion branching and merging
Subversion does not actually have a built-in branching or tagging mechanism as
such; all branches and tags are simply copies of part of the directory tree. Subversion
createscheap copiesusing copy-on-write semantics; data is written to disk only when
the copy is actually changed. The amount of extra information required to maintain
a branch is roughly proportional to the difference between the branch and its parent.
This characteristic has some drawbacks, though. Subversion 1.4 has very primitive
merging support. It does not keep track of when branches were created or merged,
and does not prevent a change from being applied twice. Most developers who do at
least a moderate amount of merging usesvnmerge.py,*which keeps track of this
metadata in Subversion properties.
There are many different paradigms for how branches are used. Here are some of the
most common ones for web development:
Production branch
The trunk is used for ongoing development. When a feature is fully developed
and tested, it is merged into the production branch and deployed. This style is
well suited to web applications, which tend to have a single development team
working on one feature package at a time. Urgent production defects can be
fixed in the production branch without disturbing feature work, and later can
be merged into the trunk.
For typical web applications, there is only one release branch, as there is only
one version of the software running at a time. When multiple release versions
must be supported, the production-branch model is strong, as multiple branches
can be created. This can be useful on occasion even in web applications; for
example, a large feature release can be staged as a “beta” to a subset of users.
If the beta is long-lived, it is useful to create a branch so that development can
continue independently.