Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic SYNERGY (steve huntington)
Decrease font size
Increase font size
Topic Title: change of release id for a task
Topic Summary:
Created On: 10-Aug-2007 20:26
Status: Read Only
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 10-Aug-2007 20:26
User is offline View Users Profile Print this message


Yogendranath Reddy Tanguturu

Posts: 1
Joined: 10-Aug-2007

is it possible to change the release id for the task once the task is completed.
the problem i am facing is:
I had linked one task to one relase and i ahd completed the task.Later they want to move this task changes to new release.How can I do that one.I had created the task from the Synergy Changei.e from CR.
Report this to a Moderator Report this to a Moderator
 10-Aug-2007 21:46
User is offline View Users Profile Print this message


Ron Zorn

Posts: 13
Joined: 8-Apr-2004

Yogendranath,

This is possible either via the command line, or the classic client within Synergy, as you will have to do this with at least build_mgr role. (it may require ccm_admin, I don't have a session here to test that right now). On the command line, you can simply query for the task with a "ccm query" command, and then with the "ccm attr -m release -v @" command, you can change the release attribute.

From the Classic gui, simply go to Tools-Task-Browse, and look up the task. When you have it in that window, choose the "views" menu from the top of that window, and choose "information". This will take you to an editable form of the task screen, where you can change the release value as long as you have the sufficient role.

Let me know if you have any problems.
RoN

-------------------------
RoN Zorn
Beacon Associates Inc.
RZorn@beaconassociates.net
Report this to a Moderator Report this to a Moderator
 16-Aug-2007 09:54
User is offline View Users Profile Print this message


David Dubreu

Posts: 43
Joined: 21-Aug-2003

Hi,

Ron's way to do is correct if the task has been created in the wrong release (developer's mistake).
If the task has not been released and if the changes hold by your task have to be followed up to the next release, then there are several methods.
1) make a baseline containing this task in the release N, if N+1 release is based on N release and N+1 release is free of baseline (tagged N+1) then here you go.
2) parallel releases : if this is maintenance (release N) and you want to put it into development release (release M), then just add this task in the build management folder of M release prep project and make a baseline, with default reconfigure template, everybody will receive changes on a reconfigure.

David.
Report this to a Moderator Report this to a Moderator
 17-Aug-2007 06:27
User is offline View Users Profile Print this message


Ron Zorn

Posts: 13
Joined: 8-Apr-2004

David,

Thank you for bringing up these alternative scenarios, however, one hole that I see, and this may be completely due to the level of CM responsibilities that your project is held accountable for, that my project lead would never let me get away with having a task simply copied into another release without having a full review of the development group to ensure that all file changes are on the leaves, and that just adding the task without this review could create issues from conflicts that may go unnoticed as well as the fact that our CCBs would not understand an identical task in two different releases, as it would not have the unique tagging that each of our changes are held to. But as I said, in a looser organization, a simple migration like you have detailed is completely valid.

RoN

-------------------------
RoN Zorn
Beacon Associates Inc.
RZorn@beaconassociates.net
Report this to a Moderator Report this to a Moderator
 17-Aug-2007 14:08
User is offline View Users Profile Print this message


David Dubreu

Posts: 43
Joined: 21-Aug-2003

Hmm... (troll ? flame ?)

You are free to do a meeting with all developers each time a task is transferred elsewhere but CM philosophy is to improve development cycle and not to slow it down... CM can manage that.
Anyway, here I talked about potential cases. Tests before baselines are mandatory, implicitly.

"Changes on the leaves" -> ROFL ! With a big development team splitted because of localization in different cities, work for different releases and even different platforms, you can't have all changes on the leaves each time a task is needed in an other release. How do you manage parallel releases with a collaborative development spirit ?

About tasks and releases (not only if releases are parallel ; i.e : using prep baselines), changes carried by one task can be implemented in two different releases and it is regular to copy this task in the appropriate folder, multiples reasons can lead to that. I dont get why it is so unhealthy in your company and why you deploy such endeavours for everyday stuff.
If you want to tag the will to populate different releases with the same changes/task, let's use Synergy/Change. In CM the tag applies to a configuration and not only to a simple task.

There is not only one way to manage a development project, not only one way to build a configuration, not only the Ron Zorn's way.
But, apparently, in the wonderful Beacon Associates's World... problems never come up!

David
Report this to a Moderator Report this to a Moderator
 22-Aug-2007 05:49
User is offline View Users Profile Print this message


Ron Zorn

Posts: 13
Joined: 8-Apr-2004

David,

Please forgive me if I sounded at all flamish, I did not mean to sound that way. I have been working with some fairly large development teams, over the years between a few hundred, to several thousand, however, much of my work has been on government contracted work, or items that had severe safety or environmental impact, so the groups were most likely held to different standards than others. You are completely right, your method does get the job done, I was just trying to cover the bases in case the original poster was strapped down to the strict process limitations I have.

Again, I did not mean to aver that there was only one way, just that there are different approaches according to your environment.

Thank you for showing me how things go on the outside.

RoN

-------------------------
RoN Zorn
Beacon Associates Inc.
RZorn@beaconassociates.net
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic SYNERGY forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 15:34.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.