Version Control | 303This model is a slight deviation from the ordinary non-web software develop-
ment model. In that model, features are developed in the trunk, stable work
toward a release is kept in a branch, and finished releases are tagged by copying
them to thetags directory. The Rails framework itself uses that model.Feature branches
This is essentially the opposite of the production-branch model. One branch is
created for each new feature to be deployed. The trunk is always expected to be
stable and represents the latest stable version of the software.
Some prefer the feature-branch model over the production-branch model for web
applications, as it compartmentalizes features and isolates them from one another
during development and testing. It supports the single-deployment-environment
paradigm, but it is difficult to support multiple releases under this model.
Developer branches
Again, the trunk is a stable codebase. Each developer has his own branch that he
can use as his “sandbox” for developing and testing features. He will either
merge code into the trunk himself or submit the changesets to be integrated by
one person. Often, this is found in large teams, as it integrates well with a for-
mal code review process.*
If you have a large enough team that developer branches are necessary, you may
find yourself passing around and manually applying patches way too often. In
that situation, it may be worthwhile to consider moving to a distributed version
control system such as Mercurial or Bazaar.
Of course, the appropriate model will vary from project to project. Do not feel con-
strained by these models. Thetrunk,branches, andtagsdirectories are only the tradi-
tional conventions used by Subversion developers. You could just as easily set up
features,production, andsnapshots if it suited your fancy.
Mercurial branching and merging
Branching under distributed version control systems such as Mercurial is much more
natural. Any Mercurial repository is automatically a branch, because any repository
can pull changes from and push changes to any other repository, even between two
different directories on the same filesystem. Thus, the standard branching method
under Mercurial is to clone an entire project to a new directory, make the changes,
and then usehg pull to retrieve and merge the changes from a branch when needed.
As an example, suppose we are changing an application’s color scheme and want to
branch to keep the color-related changes together while doing other development.
First, we clone the trunk to a new feature branch:
$ hg clone trunk trunk-newcolors
47 files updated, 0 files merged, 0 files removed, 0 files unresolved- Google uses a similar method, without explicit developer branches, for its internal development. They use
NFS, Perforce, and a code review tool called Mondrian developed by Guido van Rossum.