Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Links between RTC and DNG visible only from RTC after merging DNG streams

I am experiencing some strange link behavior when doing cross-tool linking between DNG and RTC and using local DNG streams. When a link is made between DNG and RTC for one branch of a set of DNG streams, and then that branch is later merged back to the main DNG stream, the link to RTC appears to be lost from the DNG side but is maintained from the RTC side. 


Has anyone else encountered this behavior?

I am running CLM 6.0.3. 

0 votes



One answer

Permanent link

When an RTC work item is linked to a versioned DNG artifact, it is linked to that DNG artifact in a particular global configuration (for the rules about what global configuration it is associated with, see:

So you will always see the link from the work item (pointing to that artifact is the associated global configuration), but you will only see the backlink from that versioned artifact when your current global configuration is exactly that associated global configuration.   

I believe there are some DNG contexts where you are given the choice to see all work items that link to the artifact, not just to the ones linked to your current global configuration context, but we'd need a DNG expert to verify that.



0 votes

Comments

This brings up a larger question in my mind about DNG and handling links when it comes to delivering/accepting changes from streams and change sets: 

Why aren't links part of the stream/change set merge options? It seems to me that there should be another page of the stream/change set merge wizard that deals with links and whether they should come with the changes to the artifacts or not. 
Through version 6.0.4, links are ignored in the stream/change set merge process and do not come with the artifacts.
 

Can anyone shed some light on this?

In a versioned artifact, a link is part of one of the two artifacts being linked.  That artifact is called the "source" of the link ... the other artifact is called the "target" of the link.  Any link that is  owned by the artifact being merged is part of the merge process.  In the case of workitem-to-requirement links, the source of the link is always the work item.


One of the reason the system is designed this way is that if both artifacts were treated as owning the link, you are likely to have a large number of conflicts whenever you change to a new baseline of a set of artifacts which don't agree on whether a particular link exists.   Another reason is that you would never be able to create a link to an artifact in a baseline artifact (because an artifact in a baseline cannot be changed).   This would mean that if you had a baseline of requirements in your global stream, you would not be able to create new links (say, with new test cases) with those requirements.   

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,020
× 7,495
× 1,381

Question asked: Oct 26 '17, 12:09 a.m.

Question was seen: 3,933 times

Last updated: Dec 28 '17, 1:54 a.m.

Confirmation Cancel Confirm