The document is meant to introduce the Trunk and Branches strategy for revision control of an IT project. The strategy is known for its scalability and flexibility. The documents describes the procedure for both roles: the developers and the Config Manager. It is provided for better understanding of the complexity of the process and professional relation between all involved parties as well as the complexity of technical aspects. It also describes the advantages of the strategy based on real-life situations.

1. Trunk and Branches for Configuration Management
Trunk and Branches for
Configuration Management
Robert Berliński, support Mercedes Gavilan
Document version 0.7, January 29, 2012
http://www.scmsupport.com
Table of contents:
PREFACE ....................................................................................................................... 2
THE STRATEGY ............................................................................................................. 2
GLOSSARY .................................................................................................................... 2
REGIONS ........................................................................................................................ 3
POLICIES FOR BRANCHES .......................................................................................... 3
TIME OVERLAPPING ..................................................................................................... 4
EXAMPLES ..................................................................................................................... 4
REQUIREMENTS ............................................................................................................ 5
Abstract
The document describes the Trunk and Branches approach to Configuration Management. It also
describes working regions and relevant procedures.
Copyright © www.scmsupport.com 2012. All Rights reserved. Page 1/5

2. Trunk and Branches for Configuration Management
Preface
The document is meant to introduce the Trunk and Branches strategy for revision control of an
IT project. The strategy is known for its scalability and flexibility. The documents describes the
procedure for both roles: the developers and the Config Manager. It is provided for better
understanding of the complexity of the process and professional relation between all involved
parties as well as the complexity of technical aspects. It also describes the advantages of the
strategy based on real-life situations.
The strategy
A repository system by its nature provides functionality to keep track of changes and internal
mechanisms of organizing resources into groups (folders) as well as means to move resources
between the groups and compare changes. The Trunk and Branches strategy is a set of rules for
using the repository functionality in a Configuration Management process.
However the model introduces additional complexity it is worth a recognition for its benefits:
 better control and security of the code - separates the production version from the work-in-
progress version, imposes access control and manage read/write rights for each branch and
the trunk,
 support for parallel projects - allows to separate changes between branches, e.g. distribute
changes based on different delivery date or based on different functionality/skills, improves
manageability for the changes and allows better assignment of tasks to employees, therefore
improving the overall efficiency,
 flexibility to satisfied unexpected business requirements to divide scope of a project,
postpone or obsolete selected parts, therefore giving better manageability in terms of time,
resources and costs required for a project.
Glossary
The following are some elementary terms used in the filed.
Version control repository – technical resources (server + file space + software) that serves as
file storage and control/report for changes that took place in the history of the repository,
examples: Rational Clear Case, Subversion (SVN). Related terms Revision control, also known
as version control and source control.
Config(uration) Manager – role for a person in the process of Configuration Management. The
role is central between Developers, Project Manager and Administrator and carries important
responsibilities:
 based on servers prepared by administrators configures environments for developers,
 supports developers at the starting time with the new environments,
 supports developers regarding repository and the overall CM process,
 manages the repository, e.g. merges and retrofits code,
 supervises developers resolving code conflicts,
 builds applications, deploys applications to unit test regions and delivers to administrators,
who deploys to business regions,
 facilitates application's statists and log files,
 etc.
Copyright © www.scmsupport.com 2012. All Rights reserved. Page 2/5

3. Trunk and Branches for Configuration Management
It is recommended that the Config Manager will have at least basic experience and knowledge
with regards to programming and administration. Additionally the person should display higher
standards of work including but not limited to punctuality and responsibility as well as resistance
to stress situations and pressure.
Regions
The regions are procedures and groups of technical resources (like application servers, databases,
developer’s tools, etc.) combined to establish work environments where specific group can
performing their Configuration Management and/or Production responsibilities. The process
starts from developers regions and reaches its goal in production.
Name Localization Data Actors: access Purpose
Dev Close to A few Developers: full access Coding, elementary unit
developer records, tests
(developer’s non-
PC) production
Unit Test Centralized Very Server Administrator: full access Unit tests, integration
for IT limited, Config Manager: deploy application tests, elementary
team/project non- Developers: read/write/update data functional tests,
production continues integration
User Test Centralized Limited, Server Administrator: full access Regression, Functional
for Business non- Config Manager: submit application tests
team/project production Developers: read data
Business: application
Pilot Centralized Copy of Server Administrator: full access Pre-production tests on
for Business production Config Manager: submit application real data
team/project Developers: read data
Business: application
Production Centralized Production Server Administrator: full access Production
for Business Config Manager: submit application
team/project Developers: limited
Business: application
Hot fix Centralized Copy of Server Administrator: full access Fixing critical and
IT Production Developers: full access on request urgent production
problems.
Policies for branches
It is recommended to open branch, when:
 there is a goal for given group of changes (the changes can be grouped with regards to
functionality, delivery time, skills, or other aspects that requires management).
 there is a need to separate some changes from an exiting group (in this case one branch
can be divided into two or more, where each branch keeps track of separate sub-group).
 different projects overlap in time, eg. opening new project before merge the previous to
trunk. It could be used for better efficiency and eliminating idle time.
Usually the group of changes should include at least a few changes. It is recommended to have
branches for group of changes that will take a few weeks to a few months. Due to the costs of
managing branches it is not recommended to start a branch for one or a few small changes that
will take one or a few days, unless it is absolutely necessary. The time for delivering changes
should be given by Project Manager up-front before starting a new branch.
Copyright © www.scmsupport.com 2012. All Rights reserved. Page 3/5

4. Trunk and Branches for Configuration Management
In case of critical production issue it is not recommended to start a new brunch, but use a
dedicated Hot Fix region that should be provided as a copy of Production. In that scenario, a
developer can research the problem in Hot Fix and then apply and test solution in the same
region. Later the developer and Config Manager works to deliver the changes to Production. And
next they work to retrofit the changes to other opened branches.
Time overlapping
Time overlapping is a strategy applied to series of project for optimal usage of the time. It's based
on the observations, that there are two phases in the project when the developers usually are less
occupied:
 the start, when preparing resources and environments,
 the finish, when business takes over the application.
start cycle 1 finish
start cycle 2 finish
start cycle 3 finish
start cycle 4 finish
The overlapping should be applied with caution as overlapping too much tasks can cause to much
stress resulting in human errors.
Examples
Below are 3 diagrams showing some real-life scenarios
 diagram 1 - reopen and then extend of a close branch to fix post production delivery
issue.
 diagram 2 - parallel projects and merge from one branch to another.
 diagram 3 - overlap model of work for optimal assignment tasks to employees.
Copyright © www.scmsupport.com 2012. All Rights reserved. Page 4/5

5. Trunk and Branches for Configuration Management
Requirements
Procedural requirements with regards to the employees
 the function of Config Manager in the center between Project Manager, Developers and
Administrator; it includes but is not limited to configuring new branches for developers,
merging changes and controlling the process of resolving conflicts, building code and
cooperation with administer on deployment, cooperating with the project manager.
 the procedures for Developers, like checking-out, checking-in, updating, commenting
changes.
Different group are technological requirements:
 Central repository server (e.g. Linux server with Subversion and Apache) with defined
users and their control rights as well as backup process.
 Separate workspaces (e.g. databases, application servers) supporting each branch as well
as Pilot and Hot Fix regions.
 Plugin/utility for developers to integrate version controlling into their working
environments (e.g Tortoise SVN).
Another system, that might be used for Java projects with RAD is IBM Rational ClearCase. It
provides useful mechanism of labeling versions and config specs files (configuration
specification).
Here is an example of a config spec (source http://en.wikipedia.org/wiki/IBM_Rational_ClearCase):
# Show all elements that are checked out to this view, regardless any other
rules.
element * CHECKEDOUT
# If an element has a version on the 'module2_dev_branch', then the latest
# version of this branch shall be the visible version in this view.
element * .../module2_dev_branch/LATEST
# For all files named 'somefile', regardless of location, always show the
latest version
# on the main branch.
element .../somefile /main/LATEST
# Use a specific version of a specific file. Note: This rule must appear
before
# the next rule to have any effect!
element /vobs/project1/module1/a_header.h
/main/proj_dev_branch/my_dev_branch1/14
# For other files in the 'project1/module1' directory, show versions
# labeled 'PROJ1_MOD2_LABEL_1'. Furthermore, don't allow any checkouts in
this path.
element /vobs/project1/module1/... PROJ1_MOD2_LABEL_1 -nocheckout
# Show the 'ANOTHER_LABEL' version of all elements under the
'project1/module2' path.
# If an element is checked out, then branch that element from the currently
# visible version, and add it to the 'module2_dev_branch' branch.
element /vobs/project1/module2/... ANOTHER_LABEL -mkbranch module2_dev_branch
Copyright © www.scmsupport.com 2012. All Rights reserved. Page 5/5