Introduction
Most CM products on the market are what I would call "file-centric". By this I mean that the smallest unit of change tracked by the system is a single file.
These tools typically utilize the concept of a single "repository", which provides all structure and versioning to a group of files and directories. In order to access these files, a "view" into that repository is also provided. The view determines which versions of those files you actually see in your environment.
The configuration of your view of the repository would typically depend upon the concept of "tagging" the code. At key milestones all file-versions currently displayed within your view would be "tagged" with some meaningful label. This label is then used as a baseline moving forward - i.e. when determining what to present in your view, the tool would examine each file and directory one by one. If you have not checked out your own version of any given file, it will present you with the version which matches the label you provide as your baseline.
CM Synergy is radically different. It's approach might best be described as "project-centric" and "task-centric". There is no logical centralized repository, and the smallest practical unit of change is the "task".
The CM Synergy "Project"
The physical repository in CM Synergy can best be thought of as a heap. Like more traditional tools, the repository stores all versions of all files and directories. However, unlike most other tools there is not much sense of structure within this repository. There is no root node, no way to draw any parallel with a file system.
Instead, CM Synergy relies on what it calls "projects" to provide both the structure of, and the access to, a group of related files and directories. Conceptually, this project crosses the typical boundaries of a CM tool by providing both a repository and a view.
All work performed in CM Synergy must be done through a project. In fact, the project itself is a configuration item. In order to modify a file, you must first "checkout" a version of the project in which it resides.
Upon checkout, the tool will automatically create a new version of the project in the repository and a workspace in your file system, called a "Work Area". This work area exposes the proper versions of all files and directories contained within the project. Throughout the remainder of this document, I will use the term "project" to mean the sum of all versions of that project. The term "project version" refers to a specific instance of a project - created upon checkout for a specific use.
Because a work area is an isolated region in your file system, it is generally not practical to attempt to access files from any other project. This means that the project structure within CM Synergy is absolutely critical. You must choose your project hierarchy with great care. If you make your project hierarchy too finely grained, developers will have to check out several projects in order to do their jobs. This leads to very complex dependencies, and further complicates builds as you must find a way to let the build scripts know where in the file system each project's work area resides. If it is too coarsely grained, developers will have to check out much more than is necessary in order to do their job, leading to unacceptable performance of the tool.
The CM Synergy "Task"
In addition to the concept of a project, CM Synergy introduces another concept - the "task". A task can be thought of as a grouping of changes made to an arbitrary number of files which, when taken together, make up a single logical change to the system.
As an example, a developer might be required to change the contents of a dialog box. Let us suppose that in order to do so, she must modify two Java source files and one properties file. When she checks out a version of each of these files, she must give Synergy a task number with which to associate the newly created file versions. When all work needed to implement the requested change is complete, the task itself - not the individual files - is checked in. The task is the smallest practical unit of change used within CM Synergy.
"Baselining" in CM Synergy
CM Synergy does not use the concept of "labels" or "tags" within the repository to mark a baseline. Instead, because the project itself is a configuration item, a baseline is created by simply checking the project version in. This is known as "releasing" a project, and should only be done by the CM team. Once released, the project version cannot be modified. It provides a permanent record of the exact configuration of the project at the time the version was released.
When you check out a project, you must tell Synergy from what existing version you wish to check out. This becomes the default baseline for your newly created project version.
Note: With version 6.3 of CM Synergy this is no longer entirely accurate. You can now provide an ordered list of possible baselines and allow the project version to automatically select the most appropriate one.
"Releases" in CM Synergy
In addition to specifying a project version's baseline, you must also tell Synergy towards what release of the software your new project version is working. This also holds true when creating a task. It is this release value which is used to calculate what version of what files to present to you in your project version.
Reconfiguring a Project Version
You do not necessarily want each project version to have the same view of the project's repository. You want to control which changes you can see at any particular moment in time.
For example, a developer doesn't want to automatically see every change made by every other developer as soon as it is made. This could lead to a perpetually broken build, and very slow progress indeed. Likewise, when preparing a build for an integration test, you don't want the last minute changes of developers creeping (sneaking?) in uninvited.
The process of allowing the tool to select the appropriate versions of files and directories and updating a project version to expose these files is called "reconfiguring" the project.
The reconfigure process can be customized to some degree by the CM team. However, the basic process remains the same. When deciding what versions of files are to be displayed in your project version, CM Synergy begins by examining the project version's baseline. On top of this baseline, it will apply the changes made by some collection of tasks. For developers, this will most likely be all tasks which have passed an automated build and test process. For project versions used for integration testing, this list of tasks will likely include all tasks checked in by all users which match the current release. It is in selecting exactly which tasks to include in which project versions that the customization begins.
Reconfigure Properties
The selection of tasks to include in a reconfigure operation are determined by the project version's reconfigure properties. Reconfigure properties include the project version's baseline, the release to which it is targeted, and one or more folders which contain tasks. The CM team (or those to whom we delegate authority) may add tasks to a folder manually, or the folder itself can be set up to automatically add tasks based upon the result of a query of the Synergy database. This query will be run whenever a reconfigure operation is carried out upon the containing project version.
Reconfigure Templates
In order to avoid having to set up these reconfigure properties for each new project version that is created, the CM team can choose to create reconfigure templates. A reconfigure template will take a boiler plate description of a set of reconfigure properties and fill in the appropriate values for baseline, release target, etc. based upon values chosen during the checkout process. It will also create folders to capture tasks appropriate to the project version's purpose.
Project Purposes
This is the final piece of the puzzle. When checking out a new project version, you must tell CM Synergy the purpose of the new version. This purpose value is used by Synergy to determine which reconfigure template to apply. A developer would check out their project version for the purpose of "Isolated Development", while a project version used for the first round of integration testing would be checked out with the "Development Integration Testing" purpose.
