Workspaces and Delays

A Brief Detour from talking about branching. There are risks with branching, there are other paths that lead to deferred integration, and all the issues that arise from that.

One risk of branching is that work done on a branch is work that isn’t being integrated with the Main Line or with other developers. Often I’ll hear people say that the answer to the problems of delayed integration is to not use branches. But focusing on the mechanics of branching is secondary to time to integration. Even if you don’t branch, you most likely have work that isn’t being integrated. That isn’t bad per se; developer workspaces are essential. But by itself not branching doesn’t address the problems that branching badly.

Most all teams use a model where developers work in their private workspaces until code is ready to share. These workspaces have unintegrated work, and unintegrated work sitting in a developer workspace for a long time has the same risks as work on a branch . Work in a local workspace - and not in a version repository — presents more risk because that work can be lost more easily.

Using your version management tool well is the answer to avoiding the pitfalls that branching can cause, and help you to be more productive.

Rather than talking a Pyrrhic approach to using your SCM tools, consider what a reasonable time to integrate would be for your team, and try to understand how to best achieve that time.

Next: Why moving slowly might seem like a de-risking approach but really isn’t