![]() |
Telelogic SYNERGY (steve huntington) | ![]() |
profile :
search :
help :
dashboard :
calendar :
home
|
||
|
Topic Title: Synergy/CM 6.4 Topic Summary: Folders Created On: 6-Nov-2006 22:21 Status: Read Only |
Linear : Threading : Single : Branch |
![]() |
![]()
|
![]() Answer: My understanding is that the next release should include all build management functions in the Java client. Their intention, I believe, is to remove the classic client from the product once all functions (including ccm_admin functions) are in the Java client. Implementing the Java client is a large task, so it has been phased. As most users are "developers" the developer functions were provided first, then a subset of build management functions, and in the future ... If developer projects use queries to populate their folders, then it should only be build managers and administrators that need to use the classic interface. I believe that you can run a classic client and a java client against the same database at the same time on one client (it seems to work on my Windows client machine). | |
![]() |
|
We upgraded from 6.2 to 6.4. I don't see any folder functionality in 6.4. We use folders along with CruiseControl in order to do reconfigures (given what folders to reconfigure with) before kicking of our nightly builds that is done automatically by CruisedControl. I cannot find a way to create a folder and add/remove tasks from folders in 6.4.
Also, I understand with 6.4, update = reconfigure. But the update gets the latest version of everything. What if there are some files that don't compile or have problems and I want to back them out? Before with folders, all I had to do is remove the task from the folder and reconfigure to remove all files associated with the task. It seems now by getting the latest of everything, that I'm forced to go and unuse all files that are part of the task that included the faulty file, because there may be dependencies, so I can't just remove the file that is in error but all files that would be part of the same task that caused the error. Any comments on these matters would be greatly appreciated. Thanks. |
|
![]() |
|
![]() |
|
The "classic" interface (4.2 style) is still available.
On windows client it is (by default) under Start/Programs/Telelogic/SYNERGY 6.4 tools/SYNERGY CM Classic I imagine it is also available on Unix clients. |
|
![]() |
|
![]() |
|
Do you know if Telelogic plans on implementing the folder functionality in its Java Client? Its seems as thought Telelogic is promoting using the Java Client since its the application thats run when clicking on the desktop icon. We wanted to use the Java Client because it supports extending the properties dialog for a task (i.e. adding custom properties). But from what I understand the 'Classic' gui doesn't support this. So, its inconvenient to be flipping back and forth from running the 'Classic' gui to support our folder functionality, then running the Java Client to use the custom task properties.
|
|
![]() |
|
![]() |
|
My understanding is that the next release should include all build management functions in the Java client.
Their intention, I believe, is to remove the classic client from the product once all functions (including ccm_admin functions) are in the Java client. Implementing the Java client is a large task, so it has been phased. As most users are "developers" the developer functions were provided first, then a subset of build management functions, and in the future ... If developer projects use queries to populate their folders, then it should only be build managers and administrators that need to use the classic interface. I believe that you can run a classic client and a java client against the same database at the same time on one client (it seems to work on my Windows client machine). |
|
![]() |
|
![]() |
|
Michael,
Thanks for your responses. They help a lot. But I am curious about the distinction between build management functions and developer functions in regard to folders. As I mentioned earlier, our developers use folders. We have established the following paradigm: We have 2 folders. One is an 'Unstable folder' which contains tasks that have not been integrated and tested in our testing lab. Our CM person makes an integration build integrating all tast from this folder to be tested. We have another folder 'Stable folder' that contains all tested and released tasks (which we call our 'current' baseline). Typically our developers would update/reconfigure using the 'Stable folder' to get the tested/released versions and then develop from that. Occasionally, if a developer is dependent on something another developer worked on and hasn't been tested yet (ie. in the 'Unstable folder'), they would just include the task in the reconfigure properties along with the 'Stable folder'. From your last comment, you make a distintion between developers using folders and build mgt using folders. Is our paradigm for our developers using folders uncommon/unique?
|
|
![]() |
|
![]() |
|
The Classic client will be around for at least one more version. Version 6.5 will have more functionality moved to the Java Client and 7.0 will move more if not all.
Example - migration is supposed to be in classic for 6.5 and moved to Java client in 7.0. Telelogic had a web cast yesterday (11/08/2006) announcing current and future releases (6.5 & 7.0) and what functionality was slated to be included in each. This web cast should be available later on the website. ------------------------- Thanks, Brian |
|
![]() |
|
![]() |
|
The general approach that I have been taught and generally use is "developers get what they are given; they do not choose". Developers may be given tasks by queries to populate folders (set up by build manager), or by build managers explicitly adding tasks to folders.
However, I also use a "peer review" project purpose which takes two folders:
Peer-review tasks (manual population by reviewer) With this the reviewer adds the task(s) to be reviewed to the manual folder and reconfigures. Reviewer can then check the source and/or function as appropriate, safe in the knowledge that the only changes from the approved code are those being reviewed, and therefore any abnormal behaviour must be due to those changes. Regarding your specific process, the general rule is "do what is necessary for you to work effectively in your environment". It is a risk-benefit trade-off that needs to be made: is the risk of the work being nugatory outweighed by the benefit of not holding up development if the base work is OK. In terms of the "Clasic" development and "RAD" development approaches typically given as examples by Telelogic, you seem to be implementing "Classic with the option for individuals to go RAD". |
|
![]() |
Telelogic SYNERGY
» SYNERGY/CM
»
Synergy/CM 6.4
|
![]() |
FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.