The other thing to consider is that the granularity of promotions needs to change as the process gets closer to release or production. For instance, early promotions from sub team to whole team can be done in small chunks, but when promotions target testing and eventually production or release, the promotions are increasingly larger, or incorporate larger sets of changes.

In my experience using Telelogic Synergy, this is accomplished by defining a CM Process that starts by promoting the developer defined change set (Task in Synergy speak) but then transitioning to Change Request promotion for promoting to testing environments and production. In Synergy’s case, Change Requests group a set of related Tasks. I think this flexible approach to promotion works really well and doesn’t have some of the problems of a file – branch method I outlined above.

But once you get into testing, I think source code promotion has really run its course. You don’t test source code outside of static analysis. Most teams test built binaries of some sort. The problem then is about managing builds and tests of those builds as they move through the SDLC.