March 1, 2021
Hot Topics:

Introduction to the Next Generation of Source Control

  • By Aleksey Shevchenko
  • Send Email »
  • More Articles »

The preceding exercise shows that developing with help of Synergy CM can help you establish a new abstraction level that allows you to group changes to files into logical tasks.

Here are few more key features that Synergy CM provides:

Checking in files without completing a task

A developer can check in individual files without completing a task. This means that collaboration between developers is possible even when the task is not yet completed (see Figure 5).

Figure 5: The task is not completed, but one file is already checked in

Multiple developers can checkout the same file at the same time

Parallel development is a powerful mechanism that allows developers to share source files even if separate changes need to be made to the same file (see Figure 6).

Click here for a larger image.

Figure 6: The same file is checked out by two developers

Full merge and compare features

Synergy CM allows developers to compare and merge versions of the same file. This feature is especially helpful during parallel development (see Figure 7).

Click here for a larger image.

Figure 7: Two versions of the same file are compared for differences

Fix Tasks

Synergy has a concept of a Fix Task. Fix tasks are created to fix a regular task. Because Fix Task is associated with a regular task, one can relate bug fixes to enhancements.

Multiple Release Lines

Synergy CM supports multiple release lines. This is a great feature that I use extensively in my day-to-day life. Here is how it works and why it is so essential to a successful application development process:

A "Release" is a snapshot of specific versions of files. Assume for a minute that you have an application called "ATM". The application has only three files: ATM.java, Bank.java, and Customer.java. Under Synergy CM, a new release is created: ATM version 1.0.0. This release has all three files. There is only one version of each file.

Release: ATM/1.0.0


  1. ATM.java, version 1
  2. Bank.java, version 1
  3. Customer.java, version 1

Suppose you have to implement three enhancements for this application:

  1. Enhancement 1: "Withdraw" function
  2. Enhancement 2: "Review Balance" function
  3. Enhancement 3: "Get Last 5 transactions" function

Your developers create three tasks (Task1, Task2, and Task3), check out files associated with each task, make coding changes, unit test the changes, check in code, and complete tasks.

Say you want to release two out of three changes to QA. For that purpose, you create a new release with a different version—ATM/1.0.1. At the point of creation, ATM/1.0.1 and ATM/1.0.0 are identical.

Once the new release is created, you "move" (how tasks are moved between release is beyond the scope of this article) your two enhancements (Task1 and Task2) to the new release. Now, if you compare releases 1.0.0 and 1.0.1, you will observe that the releases differ; 1.0.1 does not have changes associated with Task 3.

Now, what are the benefits of what you just have gone through?

ATS/1.0.1 can be used to create a QA build. You now have two snapshots: Development environment and QA. I can affectively continue developing in the development release (ATS/1.0.0) without disturbing the code that is intended for QA (ATS/1.0.1). If, for example, you need to fix bugs that are uncovered as a result of QA testing, you can do that in ATS/1.0.1, re-release the code to the QA environment, and not worry that the changes related to Task3 are included in the build.

You now can know and have immediate access to a code base that is relevant to any environment—be it development, QA, or Production.

Furthermore, you can work on multiple development efforts under the same application without the risk of mixing code.

I have to mention that taking the approach of multiple releases is not without its dangers. Let me give you an example.

The ATM.java class has been modified as part of Task1 and Task3. Version 2 of the file belongs to Task3 and version 3 belongs to Task1. When you "move" Task1 to release ATM/1.0.1, you inevitably carry over changes that had been made as part of Task3. To alleviate this problem, Synergy CM has something called "Detect Membership Conflicts." The "Detect Membership Conflicts" function will let you know that your file contains code that does not belong in the release (see Figure 8).

Click here for a larger image.

Figure 8: This listing is produced by the "Detect Membership Conflicts" function

Page 2 of 3

This article was originally published on May 2, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date