![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
Topic Title: Reconfigure behavior when parallel versions Topic Summary: Why merge arrows are not used by reconfigure process ? Created On: 9-Feb-2006 15:51 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() |
|
This is my problem :
I've got 2 releases v1 and v2 (v1 is my software version used for production, while v2 is being developped). I've got a source file dummy.c with 6 different versions : (here is the copy of ccm history command) dummy.c~1 v1 Predecessors: Successors: dummy.c~2:fmb:3 ***************************************************************************** dummy.c~2 v1 Predecessors: dummy.c~1:fmb:3 Successors: dummy.c~3:fmb:3 dummy.c~2.1.1:fmb:3 ***************************************************************************** dummy.c~3 v2 Predecessors: dummy.c~2:fmb:3 dummy.c~2.1.1:fmb:3 Successors: dummy.c~4:fmb:3 ***************************************************************************** dummy.c~4 v2 Predecessors: dummy.c~3:fmb:3 dummy.c~2.1.2:fmb:3 Successors: ***************************************************************************** dummy.c~2.1.1 v1 Predecessors: dummy.c~2:fmb:3 Successors: dummy.c~3:fmb:3 dummy.c~2.1.2:fmb:3 ***************************************************************************** dummy.c~2.1.2 v1 Predecessors: dummy.c~2.1.1:fmb:3 Successors: dummy.c~4:fmb:3 ***************************************************************************** In summary, I've got 2 branch for this component, merged from version 2.1.2 (release v1) to version 4 (release v2). I've made a manual merge for this. My problem is that the modification date of version 2.1.2 is more recent than the one of the version n°4, so reconfigure use the version n°2.1.2 in my project. I would like the reconfigure process to use the merge arrows, that is to say : search for the version without any successors and use it. Any suggestions ? Thanks, Jerome |
|
![]() |
|
![]() |
|
Hi !
It appears that the version 4 has been created with a merge from versions 3 and 2.1.2. So it's impossible that the version 2.1.2 is more recent than the version 4. The reconfigure select the version 2.1.2 because you are ine a project version used for the release v1, reconfigure properties don't have the v2 task used for the merge. The reconfigure is based on tasks, not on the history view. David. |
|
![]() |
|
![]() |
|
Thanks for your answer.
I confirm that version 2.1.2 is more recent than version 4 because the merge has not been made through CM Synergy automated merge : one developer has made the version 3 and 4, and then has reported his modifications to version 2.1.1, creating the version 2.1.2. I have forgotten to say that the release of my project is v2, but reconfigure process of CM Synergy do not use the reconf_release_score attribute for this project. I think the only solution I have is to set this attribute to TRUE for my project and reconfigure will then use version 4. This will solve this problem but I think that it does not significate that the merged version will always been used. For example, I also have one particular configuration where the 2 versions of an object that need to be merged are associated with different versions and the merge version is associated with the foirst of these release. In this case, Reconfigure with reconf_release_score will use the only version with release corresponding to the release of the project and not the merge version... I am not sure to be clear but It seems to me that only a reconfigure process based on predecessor-successor notions will solve all my problems. Is it possible with CM Synergy ? |
|
![]() |
|
![]() |
|
I advise you to not use reconf_release_score.
Look at this bulletin : https://support.telelogic.com/en/synergy/kb/show_content.cfm?id=1893 You can solve your case with a better use of CM Synergy practices. First use tasks for your changes if it is not the case. Then a developer should not report his change like that but from v1 to v2 with a interactive merge. A "development change" (v2 release) must not be reported in the production release (v1). For each release, create a complete development cycle with the purposes available (insulated development, integration testing, system testing) ; you can adapt it for your needs. Then all work made for v1 which have to be reported in v2 should be associated with tasks that you will put in the v2 integration testing environment. And only here are resolved conflicts caused by reported tasks between releases. Only here you can get the version 2.1.2 change. If your project's release is v2, to get version 4 of dummy.c is right. Looking the result of your history command, version 4 has version 2.1.2 as predecessor, did you add the link manually ? If not, the version 4 has been created by a merge between 3 and 2.1.2, and that look more logic because the modification's report is v1 to v2. David. |
|
![]() |
Telelogic SYNERGY
» SYNERGY/CM
»
Reconfigure behavior when parallel versions
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.