CM Synergy version problems for XYZ db - why is process so slow?

Sameer Deshmukh's picture

Question asked to me by Build engineer to resolve below problem:

Checking-in objects (around 1000 or may be more) has become painful now. It takes at least 3-4 hours; ideally, it shouldn’t take more than one hour as compared to other synergy location.
The problem is version handlings in our database which creates long versions and to manage versions for so many objects I have to take back-ups, remove folders from directory and create completely new object versions which are really time consuming processes.

Risks in this process:
1. Even after doing so much manual process I cannot make sure whether I have checked-in all the required files.
2. Losing folders/directory history every time this is done.
3. If build failure happens after Rte task, is a tedious job to identify root cause
4. It may create parallels
5. Delay in release consequently final release

We need to grab CM Synergy administrator’s attention to resolve this issue ASAP otherwise I am not sure how Rte work will be evaluated. Rte already has enough processes to follow, adding such undesirable step is really discouraging

6 Answers

David Honey's picture

Hi Sameer,

This sounds like something is wrong with your process. Replacing an object version with a completely new instance that has the same contents just because of some version attribute length issue seems like a poor thing to do for several reasons. Firstly, you have to create new versions of any directory in which that object should be bound, and this potentially creates parallels that have to be merged. Secondly, you lose traceability because there is nothing to relate the new instance with the object version from which it was copied. Thirdly, detection of membership conflicts is likely to be negatively impacted because of this lack of dependency information. It seems to me that this is just creating more issues than you are trying to solve.

Long version strings are more likely when products are automatically checked out during a build using ObjectMake. However, your build process could explicitly use a version naming scheme, including something like a build number. So instead of some long dotted-branch-notation string such as "" use "int1.0_1234" where "1.0" is the release, "int" means it is an integrate test build, and "1234" is the build number. The build script could explicitly perform such check outs, or it could amend the version numbers after automatic check out. This should probably be an automated part of your build process.

If you have long version strings with dotted-branch-notation on source objects (not products), this suggests that developers are either creating too many parallels and/or when merging are not selecting the main branch first, or not taking care to change the version string to something more meaningful. For example, say two developers check out from version 1, giving parallel versions 2 and 1.1.1. When merging those parallels for the main branch, you want the merged version to be 3 rather than 1.1.2. If the developer selects 2 first, then 1.1.1 second, then the default next version will be 3. If the developer selects the opposite order, the default next version would be 1.1.2, and it would be better for them to change the version to 3. If this mistake is repeatedly made, you end up with long and largely meaningless dotted-branch-notation version strings.

You should also know that Synergy 6.5 is no longer under active maintenance. Currently supported releases are 7.1 and 7.2.

Best regards,

Sameer Deshmukh's picture

Thanks David for taking your valuable time for detail explanation.

Sameer Deshmukh's picture

Hello David,

I have another question for you suppose if i want to mass change version string of checkout objects. For example if i query all working objects in the project and run single command to change all of them in same version string?If such possibility how can I perform it?


David Honey's picture

Hi Sameer, You can query for them using the Synergy CLI or classic CLI. This sets the query selection set. You can then reference those objects in a ccm attr command using the query selection set form "@". You can find more information in the IBM Infocenter at For example: ccm query "some_query_expression_here" ccm attr -m version -v @ Note that if you are using DCM, version strings must adhere to DCM versioning conventions as described in the DCM user guide (also available in the IBM Infocenter). Best regards, David.

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.