Sometimes, You Just Need to Slow Down

• number and length of sub-branches and unsynchronized work/changes (see Lean branching)

In the context of simple codelines, branching can still make sense. For example, developers can back their workspaces with Private Branches [SCMPatterns] so that they can checkpoint small tasks. The key for the developer branches to be successful is that they are easy to execute, and that they are isolated from the main development stream for as brief a time as possible.

To maintain a simple codeline, you need to do more than to simpy decree that new work must not break existing code. You need a mechanism to validate that the code is still functional, and you need a plan for incrementally "merging" the new functionality into the application. Automated testing is the best and simplest tool for verifing the stability of the code in the face of change.

Testing and SCM
Some challenge whether testing has a role in SCM. Steve gave a talk at a conference recently, and he saw on the feedback forms more than once a comment to he effect that an attendee was disappointed that the talk covered more on testing and build time integration than on branching. It turns out that testing is a central part of SCM.  Consider the definition of CM:

• Configuration identification

• Configuration control

• Configuration status accounting
• Configuration audit and review

Automated tests provide the ability to quickly verify that the code performs its desired functionality.  Failing tests provide a clue that something has changed and thus a hint that a configuration item may be incorrect.  More pedantically you can write tests that validate packaging and version constraints. Automated testing, especially that which runs as part of a continuous integration build, can move you towards these functions by helping you verify that the application's functions are as specified and that any change meets some minimal set of criteria around maintaining existing functionality.

Being able to make changes in an incremental manner requires work on the part of the engineering and architecture teams too, but those who think about SCM can enable this change by providing the infrastructure such and Continuous Integration Environments, testing support, and tools to tie code changes to small stories or requirements that move the project along the way to the new approach incrementally.

Motivating Example
Consider a development team that needs to develop a new valuable piece of functionality that requires a potentially disruptive change to the code (for example, an API change). After looking at the work to be done, and doing some preliminary design work, the team estimates that the work will need more than one person and more than a single iteration to complete.  While this functionality is being implemented, other team members will still be working on the active code line.

The team is familiar with Software Configuration Management Patterns [SCMPatterns] and is considering two options (somewhat related) for this team:

• Create a task branch for the project. The team would work in a separate development stream, and when everything is working and they're ready to roll out the new feature, the team would integrate with the main development line.
• Work off the main development line and develop the new features in an incremental manner so that no existing functionaility breaks.

Let's explore the options in turn.

Branching: the good, the bad, and the ugly
A task branch is a traditional SCM solution to handing potentially disruptive change: "Have part of your team perform a disruptive task without forcing the rest of the team to work around them, using a Task Branch."[SCMPatterns] When the work on the task branch is complete,