CM: The Next Generation

to check-in the stability affecting portions of a new feature well in advance of the rest of the functionality, so that re-stabilization may occur early on in the cycle. As well, a problem may apply to multiple streams, whereas a change may have to be implemented separately for each stream. A change is different from a task or an issue/problem.

One of the key aspects of a change object that will become more and more visible is its status, or promotion level. In a third generation system, you don't simply promote file revisions by promoting the change, the change status is the promotion level. There's really no need to talk about promoting file revisions and no need to label them. They're creations of the change. A third generation system will look at the changes that have been promoted and tell you what your new baseline is, or allow you to look at several baselines simultaneously in a given stream, each for a different promotion level. You won't have to create parallel branches as you might have to today because the tool lacks the ability to give you a change-based view of the system. Unfortunately, this will be a much more difficult task for most tools, which grew up on file-revision based views instead of on change-based views.

All in all, the introduction of more first order objects and the elimination of branch-based promotion will significantly reduce the need to branch, label and merge. Change-based promotion will also make it easier to pull changes out of a build, simply by demoting the change status. Configuration Management will tend to be the task the tool does. Humans will focus on Change Management and the tool will use that input to automate the CM function almost entirely.

The integration of related management capabilities (requirements, test cases/runs, activities/tasks/features, etc) into the CM environment will allow issues of traceability and reporting to advance significantly. Some second generation tools have a number of integration capabilities bolted on. This will not be sufficient from a third generation perspective. You must be able to navigate quickly, using a point-and-click capability, your traceability links. Reports and views will be integrated across applications. When you compare one deliverable to another, it doesn't just give you the source code/file differences. It tells you the set of changes applied, problems/issues resolved, features implemented, requirements addressed, test runs performed, etc.

As IDE standards come into play more, there will be a greater level of integration. The file-based integration schemes will give way to change-based schemes, with to-do lists eventually showing assigned tasks and problems/issues. The CM tool will begin to look more like a service, serving the IDEs, in some shops. A combination of IDE integrations and CM tool advances will result in better Active Workspace feedback. You won't need to look at your workspace to see its state - icons, colors and other annotations will allow you to see at a glance if your workspace differs from your context view, if files are missing or and other useful information, including the normal checked-out indicators.

Beyond the 3rd generation, don't be surprised to see the CM tool evolving into the IDE. When that happens, the CM tool will also start to be used to analyze dependencies and to help layer the system, resulting in more re-usable API production. Also, we'll finally start to see CM tools that can easily integrate with non-file-based objects that need revision control. Typically a plug-in will be required to interface with a particular proprietary-format object. But in the more advanced solutions, the same plug-in will make the proprietary