7 minute read


Executive Summary

To support increased responsiveness to business needs, an enterprise is considering a move to monthly site releases. 

Increased frequency of releases places additional demands upon the engineering, QA and release teams with regard to developing, maintaining, testing, and tracking multiple lines of development.  The challenge to the enterprise is how to balance the engineering team’s need for ongoing development, which is often experimental in nature and uncertain in outcome (the “what”), with those of the business whose focus is more schedule-driven, and thus highly dependent upon calendar time (the “when”).

Developed through years of consulting in the release management space, Freepository presents a clear strategy for managing these demands through utilization of source code repository branches in Subversion (SVN).

This posting explores the “how” of managing these occasionally contradictory release management objectives.


Every branch in SVN is simply a copy of another line of development. This presents new opportunities in managing these lines of development, as their topological location in the repository maps directly to their branch name. This means that branch names – the actual lines of development – are visually evident.

Using these visual and topological cues, lines of development may be easily segregated in SVN. Simply creating (or copying) a new branch creates a new line of development that is immediately and unambiguously present, available, and distinct.

**How are Lines of Development Managed?


In SVN, a best practice has emerged that maps to the real-world process of release management.




The folders ‘branches, tags and trunk’ refer to the method of organizing your lines of development. In branches, you have as many different lines as is necessary to support concurrent development, such that activity in one line of development does not destabilize activity in another line (branch).

Tags are simply ways to “save” lines of development at specific points in time. Common uses of tags include labeling a line of development that is/was released. Using the tag, you may reproduce that exact set of source code at any point in the future.

The trunk is often referred to as “main-line”, as it is where the main line of development is stored for a project. Experimental work occurs in branches, when it is deemed “ready” it is merged back to trunk. When code is packaged and released, it is tagged.

A key point here is no ongoing, day-to-day development activity occurs on the trunk. This is in contrast to the current practice at many enterprises. The trunk is literally the stable line of development that is currently in production – nothing else.

At each production release, the release tag is merged to trunk. This ensures that the trunk always contains exactly & only the state of the current production site. This is an important point and bears repeating – no ongoing development occurs on the trunk. Its sole purpose is to maintain the state of production after the fact.

The use of the branches folder in SVN supports project- or initiative-based segregation of development.

Consider this example:



Two lines of development are currently active – Project One and Project Two. There is no ambiguity, as each project is clearly visible in the branches section of the SVN tree. Activity in Project One is independent of activity in Project Two.

At some point, the business determines that Project Three – a new initiative – is approved and development activity is going to start. A new branch is created to support this


In the same namespace where Project One and Project Two are currently under development, Project Three is now present. Its line of development may begin and progress at whatever rate is necessary and appropriate, as both Projects One and Two have been doing. This technique implies that Project One, Project Two and Project Three are decoupled; no dependencies exist, and thus these lines are truly independent.

What if there are dependencies?

A practice that I have employed elsewhere extends this technique. Lines of development that consist of multiple projects, such as site features that are dependent upon others, may be grouped together in meta-projects at inception. This facilitates immediate, ongoing integration between the articles of development in the meta-project, while maintaining separation from any other level of constraint.

Meta-projects are often given code names. This allows teams to make reference to the line of development, develop in it and for it, while keeping it separate from other activity. By using code names, the teams involved have removed the artificial constraints of schedule-based development. They are free to develop, experiment and abandon work as necessary without destabilizing any other line of development.

Continuing our example, this technique is implemented in SVN like this




Such a technique allows this related development to take place in a manner that lets the business decide when to schedule the release. This may sound confusing, but consider the case where the related activity (the set of initiatives code-named eureka in the example) is so large in scope that we cannot reasonably – at inception – estimate when it will be complete.

Using code-named based branches allows us to conduct enough engineering to make this determination, again without destabilizing any other development activity. We can then make the necessary business decisions about the release, up to and including abandoning it, knowing that we won’t have to “yank it out” of a branch where others are working.

When the projects are complete and ready to be integrated, a new branch is created, into which the project branches are merged. The integration is done when the projects are ready – not before. This decouples the engineering activity from the integration constraints usually associated with schedule-driven development.

Integration branches are used to facilitate the merging of multiple projects or initiatives into a schedule-based branch that may be tracked independently, for example:


Creation of such a branch would support a proposed release naming convention for FY08, where we are using the year number (8) scoped with major release number (1). It is clear that this technique fully supports a release name such as 8.1.1, where this would be a bug fix of major release 8.1. Subsequent releases, if necessary, could be easily made (8.1.2, 8.1.3, etc)

What does this mean?

It means that we can support multiple lines of development in non-colliding, visually apparent, and intuitively named branches. These lines may be merged when and if they are deemed ready into the current integration branch for inclusion in the next release.

When the integration branch’s articles of development pass acceptance testing, they may be labeled with a formal release tag. The release tag may then be used to identity and obtain the entire set of articles of development anytime in the future. In this respect, SVN tags are no different from CVS tags.

The key difference is that the tag is easy to produce, as it is simply a copy. Another difference is that ongoing development can be accepted on an SVN tag; though this is generally not advised, it could facilitate rapid resolution of production bugs on release night.



The Branching Strategy may be characterized as a funnel. At the top of the funnel are loosely defined, decoupled lines of development that are not fully scoped. As the lines mature, they “fall” deeper into the funnel. Nearing the bottom of the funnel, the projects are completely engineered, fully integrated with dependent projects, until ultimately they “leave” the mouth of the funnel and get merged onto the trunk.


Tags: , , ,