In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Still because the move is from a very simple file-based check-in/out model, with a pile of rules and exceptions, to a slightly more complex change-based check-in/out model, with few rules and exceptions, there will still be resistance. The CM tools that can demonstrate clear return on value to the developer, and that can ease the transition to change-based operation, will be the winners. Unfortunately, many of the add-on change package solutions have given other solutions a bad name. They instantly conjure up images of multiple tools and databases, restrictions and complexity. The third generation CM tool will have change packaging as a natural, core component, not as an optional add-on.
Workspace synchronization will be more easily automated and higher visibility to workspaces provided. Active workspace feedback will allow the user to compare any CM repository view with a workspace visually, identifying missing files and files that differ. Workspace-wide comparison and merge operations will support detailed query and synchronization processes.
The process will be supported at the user interface with the introduction of in-boxes/to-do-lists. Traceability will be established as the contents of these to-do lists are used to initiate events, such as fixing a problem or implementing an activity. The set of to-do lists will be established based on a user's role and visual indications will identify those lists in which work is queued.
Stream-based development models will become more prevalent, not because of the branching simplifications, but because it will allow users to easily filter the data they wish to see. For example, one would switch views from one stream to another to look at pending work. The age of configuration view specifications will disappear as the CM tool will use the product, stream, and possibly promotion level to establish the views, not only of source code but, of all pertinent data for the user. Especially at the management level where it is often difficult to use the CM tool to garner required data, the automatic view specifications will permit simpler data filtering and the ability to drill down from metrics to specifics for a particular stream.
Other views will be supported by specifying a specific build identifier, a baseline identifier, or perhaps even a change package, where the view would revert to the context used initially to establish the change package, whether or not it is still in progress.