CM: THE NEXT GENERATION of Branching Standards

road map.  I don't have to write a context view specification or deal with explicit file revision numbers.

What if I need to merge a change from one stream to another (i.e. change propagation)?  Well, again, the CM tool knows the product history, and the set of files involved and their histories.  It should be able to calculate which files of the change need merging, what the ancestors are, and walk me through - in case there are any conflicts - bringing me to a point for re-testing.

I don't have to worry about switching the main trunk from one release to another, because each release has a main trunk which continues forever.  I don't need to set the timing, or make sure everyone has their merges done for the switchover.  I don't have to worry about what the process is for a change that is needed in a release before or after it occupies the main trunk - it's the same for all releases for all time.

All I Really Need
So what do I need to know how to do in this scenario?  As a developer, I [b]need to know[/b] how to:

1. Specify my context (although hopefully it's remembered until I next need to change it).
2. Find my to-do list and start my changes (i.e. create my Updates) based on an item in it.  The CM tool should automatically restrict my to-do list to my context, and tag the Update with my context, and reason for change.
3. Go to the source tree and check-out a file, or perhaps inspect it to see if I need to check it out.  But the CM tool should branch it for me (possibly with a confirmation option) if necessary, and it should attach it to my Update.
4. Review (i.e. via delta report) and check-in my Updates
5. Promote my Update (i.e. after it's checked in tell the build team when it's OK for them to take it)
6. Occasionally select an Update from a different release Stream and propagate it to my current stream.

and I don't need to know :

1. What the branching strategy is for the project and how to decide whether or not to branch a file
2. How to branch and how to label a branch
3. How to merge branches, and what to do with them after they are merged
4. How to write a context view specification so that I pick up the right file versions
5. How to link my reasons for a change to the modified file revisions

Hopefully you'll conclude that the "need to" items are a lot easier than the "don't need to" items. (Perhaps I've left out a few from each list.)

Back to Reality
This is all very well and good, but if the branching model is too simplistic, how can I do all of the things I really need to do?  Are we not simply going to suffer elsewhere?  The answer is: Yes.  You are going to suffer tremendously - if you don't have the process and tools in place to help you realize this model. Otherwise: No.  So let's look at this in more detail.

Why do you create branches today? Before tossing all of this out as too simplistic, let's do the analysis.  Why do you branch?  Well first off, to support parallel releases - we've already covered that one and that's a good reason.  But there are plenty of other reasons as well:

1. To Support Parallel Releases
2. Because the main trunk is the wrong release
3. To have a place to promote file revisions through the workflow: Ready for build, Integrated, Tested, Production