Concept of Synergy collapse command is problematic

The collapse command enables you to delete object versions from the database and adjust history links. You use this command when the object you delete has successors. All collapsed objects are removed from the database. If you collapse a project, its members are unused and the project is removed.

Note Before you check in a working version to a non-modifiable state, be sure to collapse the earlier checkpointed versions you do not want in your database; otherwise, you will only be able to collapse the checkpointed versions while working in the ccm_admin role.

The immediate successor of a checkpointed version must be writable to collapse the predecessor. For example, assume you have an object named bufcolor.c with a version history of: 1 --> 2 --> 3 --> 4, where version 1 is in the integrate state, versions 2 and 3 are checkpointed versions, and version 4 is in the working state. If you want to collapse version 3, you can do so because version 4 is in the working state. If version 4 was in the integrate state, you would not be able to collapse version 3.

You can perform a collapse command on a specified object except when the object has either of the following characteristics:

• the object is non-modifiable and you are not working in the ccm_admin role

• the object is a member of a project

Note Collapsing a version that has multiple successors and predecessors links each of the version’s predecessors with each of the version’s successors. Collapsing a version that has no predecessors and multiple successors unlinks the successors’ histories.

All users can collapse objects to which they have write access.

Users working in the ccm_admin role can collapse non-modifiable objects as well.

As a matter of fact this command kind of breaks the very idea of the Synergy/CM - Task-Based CM:

Synergy/CM defines a release as a collection of tasks. It is content of this collection (and not the content of the code line) that defines what goes into release and what does not.

When an object is collapsed, this is done outside of the tasks. The operation does not require any task to perform. Thus the release content is changed without any trace left.

Change propagation is task-based as well. So if at any time we would want to propagate the specific change (task) to another version, we may propagate the incomplete change - without the collapsed object and without knowing something is missing.

And if for some reason we'll ever look at the release tasks, we'll see some empty tasks (those that held the only file that was collapsed). We'll then wonder what's the point of having an empty tasks to change the code.

Hence it does look like the collapse operation is only acceptable for non-source files, e.g. shared build products.