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

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 "6.1.1.1.1.1.1.1.1" 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,
David.

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?

Thanks,
Sameer