SCM tools are not configuration management tools

The main reason why most so-called SCM tools are not really SCM tools is because they don't support managing software configurations. Making software is more than writing source code and converting them into executable code and data models for databases. A real SCM tool would be able to capture everything that important for deploying and maintaining the software. This includes requirements, designs, models, sources, tools, infrastructure, knowledge, skills, test scripts, test data, manuals, scripts and other information.

Most SCM tools are able to capture files in a structure and control changes to the files and the structure. New files and new versions of existing files are all merely new files. Typically, the structure is 3-dimensional:

• Directory (or folders) structure
  
• Version (or revision) structure
• Branching structure
  

The directory structure may seem to be a 2-dimensional structure (i.e. nested directories and directory next to eachother at the same nesting level), but if we consider the pathname + filename as the single identifier for a file, then the directory may be considered as 1-dimensional. The version structure is 1-dimensional: the successive versions supersede their predecessors. How about parallel versions? Parallel versions are partial contributions to a single succesor version. The actual successor is a merge of these partial contributions. Branches look similar to parallel versions, but the essential difference is that parallel versions are partial contributions to a single successor while branches are full contributions (version structures) to alternative successors.

If we look at the implementation of these dimensions, then the most simple implementation is 1-dimensional: all 3 dimensions are projected onto the same implementation, e.g. as directory structure (or path+filename). The "version control tool" could be an ordinary file system. For example:

main/gui/generic/foo-v1.c
main/webgui/unix/foo-v1.c
main/webgui/unix/foo-v2.c
main/webgui/unix/foo-v3.c
main/webgui/winxp/foo-v1.c
main/webgui/winxp/foo-v2.c
R1.0.0.0/gui/generic/foo-v1.c
R1.0.0.0/webgui/unix/foo-v2.c
R1.0.0.0/webgui/winxp/foo-v2.c

The problem with this version control system is that path+filenames changes for every new version. So users and the build process have to do more work to figure out which version they should us.

The next implemention would be a 2-dimensional implementation: directory and branching are combined into a single dimension (path+filename), and versioning is the other dimension. Simple version control tools like Subversion works this way. For example:

main/gui/generic/foo.c (versions: 1)
main/webgui/unix/foo.c (versions: 1, 2 and 3)
main/webgui/winxp/foo.c (versions: 1 and 2)
R1.0.0.0/gui/generic/foo.c (versions: 1)
R1.0.0.0/webgui/unix/foo.c (versions: 2)
R1.0.0.0/webgui/winxp/foo.c (versions: 2)

Advantage is that the path+filename remains the same for all versions within a branch. But for different branches, the path+filename is different. And since directories and branches are resolved in the same dimension (the path), it is not possible to distinguish between a directory and a branch. For example, are main and R1.0.0.0 different branches? Are unix and winxp different branches? Are gui and webgui different branches? Or are they different directories within the same branch? So users have to make agreements about naming conventions to distinguish between branches, but SCM takes care of deciding (automating) which version is used.

One step further is a 3-dimensional solution, where directory (path+filename), version and branch are independent of each other. More advanced version control tools like ClearCase or Synergy are needed. For example:

gui/foo.c (versions: 1 on branch: main)
webgui/foo.c (versions: 1 and on branch: main; versions: 2 and 3 on branch: unix; versions: 2 on branch winxp)

Advantage is now that the path+filename remains the same for all versions and all branches. This simplifies the implementation of an automated build process and the description in design documents and models. But the counterside is that SCM has to have the information to decide which branch a user is working on in order to select the correct version for the user to work on. And the user may be unaware of the branch he is working on - introducing the risk that he is working on the wrong branch.
So on one side SCM makes life easier for the user and the organization (e.g. automation), but on the other side it introduces extra work to reduce the risk or to repair mistakes.

As you can see, I have left out the baseline (R1.0.0.0) from the last example. In the first and second example (1 and 2 dimensional), the baseline was combined with the directory dimension. In the last example, the baseline could be combined with the branch dimension, but it could also be implemented as a 4th dimension: labeling or tagging.

And this brings me to the point where version control enters the domain of configuration management. An essential feature of configuration management is to identify dependencies. A dependency defines which objects belong together. There are many different dependencies that can be (or need to be) identified, for example:

• Directory dependency: all files within the same directory tree
  
• Branch dependency: all files on the same branch
• Version dependency: all latest versions
  
• Status dependency: all files with the same status (e.g. release R1.0.0.0)
• Content dependency: all files with compatible content (e.g. requirements-design-code consistency)
  

The status dependency is typically modeled in a so-called promotion model. All files go through a predefined series of statuses, and files (versions) with similar status and context (e.g. branches, directories) belong together as a configuration. These statuses are for exampe: working, integration testing, system testing, released. Tools support promotion by branching (e.g. ClearCase/UCM by deliver and rebase, or Subversion by "smart"copying of directories called branching) or by selection rules (e.g. Synergy by reconfigure property templates).

But one of the biggest shortcomings in SCM tools that I know is the absense of support for content dependencies. How do you identify the impact of the change of the design on code, requirements and tests? How do you identify the impact of code changes on other code, interfaces, design models? How to maintain the content information efficiently? How to you know that the content dependency is compromised? How do you know that release 3.2 of product X does work with release 1.2 of the framework, but not with release 1.1 of the framework? How do you know that release 6.1 of product Y cannot work with product X because it does not work with framework 1.2?

Another big shortcoming of SCM tools is that they only support control on file level. They don't control requirements, components in the design model, test cases in a test specification, tool versions (e.g. compilers, IDEs, webservices). Consequently, many organizations try to capture those items in files, e.g. by creating a requirement spec that "baselines" a set of requirements. But then again, those individual requirements - although versioned in a requirement management tool - cannot be identified as separate objects in the SCM tool, let alone that dependencies on requirements level can be identified.

The only solution that I am aware of that comes close to an "SCM tool" is the Jazz platform, starting the Rational Team Concert, but integrated with the requirements, test and project management applications. Since all information is stored in a composite repository, where information objects are actually identified as objects (not as files), it becomes possible to identify relationships (such as dependencies) between objects (not only files). Yet, I doubt whether is will be capable of identifying dependencies between configurations, e.g. content dependencies between software packages.

Rational ClearCase is not an SCM tool

If Telelogic Synergy is not an SCM tool and Subversion is not an SCM tool, it is easy to conclude that IBM Rational ClearCase is not an SCM tool either. Not even ClearCase/UCM is an SCM tool.

Telelogic Synergy is not an SCM tool

In Januari I talked about Subversion being not an SCM tool. Now let's have a look at Telelogic Synergy, which has been acquired by IBM recently. Until recently, I did not have much practical experience with Synergy and most of it slipped away. Now, I am working with it quite intensively and I came to hate and love it.

So let me explain why I think Synergy is not an SCM tool either.

Promotion model
Since the introduction of the task-based, more or less as a replacement of the ancient object-based approach, Synergy has adopted the approach of change sets. Tasks are actually change sets.

In Synergy you can define almost any configuration regardless of how, where or when the objects are changed. There are a few predefined change models, e.g. Collaborative Development and Insulated Development. The difference is that with Collaborative Development all completed tasks come available to other developers, while with Insulated Development tasks are promoted manually by the build manager.

Using queries on the database you can define almost any configuration. Through (semi-)automatically updates of the configurations, objects are "promoted" to the configuration. So for this Synergy qualifies as an SCM tool.

Real baselines
With the introduction of Rapid Baselining, you can freeze a configuration of multiple components and subcomponents instantly. The resulting configuration are immutable.

So again, Synergy qualifies as an SCM tool.

No projects, teams and streams
Synergy structures a database into (what Synergy calls) projects. In fact these are not projects, but components that can be developed and released independently of eachother, of hierarchically if you wish. Calling them "projects" is misleading because they do not constitute an enterprise for an goal within an agreed timeframe, using a set of resources. Moreover, you cannot even assign people to a project (only to a database) or define a particular scope to a project.

Synergy does not know the concept of teams, or roles assigned to people in a project. It does define "roles" to assign tool privileges, but no roles in the sense of a project (e.g. project leader, librarian, developer, tester, release manager, etcetera).

It may sound strange, but Synergy does not know the concept of streams. You can create parallel configurations (called "parallel projects") and parallel versions, but the concept of "a flow of changes" (like a river meandering through woods and valleys) is missing. Configurations are more like cities (being somewhere, changing constantly but going nowhere) than like rivers (changing constantly and moving constantly). You can define concepts that look like branches or streams using the release value, purpose and platform, but they remain configurations not streams.
Even worse, Synergy is quite "parallel intolerant". There is no distinction between checking out the same version twice (with the same release/purpose/platform value) and checking out versions in completely different projects (with different release/purpose/platform value. Why would you be need to be warned that someone in another project is changing the same object as you are? I can understand why you need a warning if it happens within your own project team.

Change sets
As a wrote above, tasks (or change sets) are in the core of Synergy. It's more powerful and more comprehensively implemented than any other tool I know.

Components
At first sight, the so-called projects may be considered as components. However, since Synergy tries to be "smart" in selecting sub-project versions (or sub-component versions) there is a clash between using baselines of released components and using a development configuration of a sub-project/sub-component. Due to this smartness, Synergy sometimes selects the "wrong" configuration.

No roles
Yes, Synergy does define roles but only to distinquish between different tool privileges (e.g. developer, build_mgr, ccm_admin). Roles to separate responsibilities and authority, for supporting promotion models and release management are absent.
Although... you can define a change promotion model in Change Synergy that grants authority to promote requests. So in Change Synergy (control of requests) roles can be defined but in CM Synergy (control of configurations) you cannot.

Although some things can be customized, Synergy does not quality for SCM tool here.

Limited branching
Some branching can be implemented using release, purpose and platform, but it is rather a way to distinguish between different configuration than between different branches. Also, Synergy supports parallel versions but it is hardly sufficient to call it branching.

Conclusion
Taking all the pros and cons into account we can conclude that Synergy is a very powerful tool and it comes close to a SCM tool. Yet, it lacks several important concepts.