Another aspect to consider is whether you have a team structure where everyone on the team who is working on the same code line is working toward the same goal. If they all are, then it makes sense to work on the same code line. If your team has people working on different time horizons, then working on a single code line is harder to do.
Tying this back to the last question, a daily stand up is a great way to have the kind of communication that avoids code conflicts.
It's best to start with figuring out what development approach works best for you and having that drive the SCM approach you choose, but your SCM approach can also encourage a certain work style.
Dan Wellman: How does a project's release cycle affect this?
Steve Berczuk: Your desired release frequency most directly affects your approach to code-line management. If you release quarterly, for example, then you can get by with a model where you work on more branches targeted at different releases, and you can be less strict about encouraging that code builds and tests with each change. In some cases, having a model like that could lead to a situation where you just can't release frequently.
If you want to release more frequently, then you need practices that encourage frequent integration. The simplest way to do that is to work on a single main line and have the discipline to fix problems quickly so that the code line is never broken for long. You can also use a staged integration (or promotion) model, but that just delays eventual integration.
The more frequently you want to release, the fewer code lines you want to be working on, since each integration step between code lines can take time.
Dan Wellman: What common challenges do you see today with teams and their SCM practices?
Steve Berczuk: This is slowly changing, but there still are many teams for whom release management is seen as being over the wall from development, yet the SCM and release-management process affects so much of how developers work. This is analogous to how test and development were considered distinct before people started thinking about agile. While SCM and release management are skills in their own right, they need to be considered part of the responsibility of the development team and integrated into the development process.
As an extreme example, people have asked me about best practices for release engineers merging code. Maybe it's because I am primarily a developer, but it seems that having someone else merge changes seems like a bad idea. Trying to merge code while distanced in time from the change—and without understanding the context behind the change—makes little sense, as it's not always possible to understand a change without understanding the entire context. While the code should stand alone, it's hard to reliably capture things like the programmers’ intent and all the reasons behind a change. (Brad Appleton once wrote a pattern about this: “Merge Your Own Changes”).
So, probably the biggest problem is when developers don't think of SCM and build together with development, and when those responsible for release management and build are not integrated into the development process.
Dan Wellman: Are there any new developments in SCM that you've found particularly interesting or exciting?
Steve Berczuk: Interest in continuous deployment and continuous delivery is pushing the release process closer to development, which is good. And it's likely to drive tighter integration of SCM with build and issue-tracking systems. I hope that this leads to more of a concept of delivery workflow rather than build, commit, and deploy being seen as separate steps.