Why do RRC artifact revisions and audit history not match?
Can someone tell me why a change of link (addition or removal for instance) is captured in the audit history of an artifact but does not increment its revisions. Furthermore the "Last Modified By" column in a tabular view will only show the last revision many link changes may have occurred after the last revision. Thus this column is useless for spotting changes (any change) to an artifact.
|
4 answers
Hi Yvon,
My understanding from the help https://jazz.net/help-dev/clm/index.jsp?re=1&topic=/com.ibm.rational.rrm.help.doc/topics/t_view_artifact_revs.html&scope=null A revision is created each time you save an artifact But a comment, link, attribute can be created without opening the artifact editor and modifying the text, i,e a link can be added to the artifact from another artifact. So to me a revision is more when the primary text content changes, where as the audit history is any change effecting the requirement. |
|
Thank you Robin for your answer. I already am familiar with RRC usage and operation. What bothers me here is that "Last Modified By" only displays revisions rather than any change that occurred to the artifact which is what the column name implies. Thus I cannot trust the column and I really question its value. Furthermore whether I can make a change without entering the editor should not discharge the tool from its responsibility to create a new version of the artifact. The audit history shows the correct number of versions of it. In real-life links to specific versions of artifacts are definitely part of the version of any given artifact. For instance a use case is linked to a number of other requirements that make any of its statements testable. I look at a version of it a week or 2 ago. I need to have a true picture of its links. In RRC 2 changing a link triggered a new revision of the artifact because you had to save it. So the "Last Modified By" was always correct. It showed any change to the artifact. This is a software engineering concept. It is an integral part of UCM. It should equally apply here. |
In 3.x and beyond, "traceable" links are actually stored outside of the artifact (same as comments) therefore adding such a link (or comment) does not in any way alter the artifact. In 2.x, links were handled differently. They were known as "content" links which were in fact stored within the artifact and thus caused a revision to be created. While less obvious and less common, there are still some links which are "content" and consequently do not appear in the sidebar (which only shows "traceable" links). Examples are mainly in the area of the graphical editors when you insert images or reuse parts and sketches.
Hope that helps. |
Yvon Lacasse If I had the architecture to support it I would argue for links to be formal artifacts (first class entities) in an in formation model. It wouldn't impact the requirement artifact because it is its own container. The storage mechanism that we have today isn't completely this paradigm but as Stef van Dijk has outlined it is stored outside of the artifact.
We also really don't support branching (vesioning) the way that you are really expecting. We are trying to implement this now in the work that we are doing for version and configuration management (VVC) in RRC. Watch for a beta of the new capabilities in the next 6 months. We actually showcased the VVC work at Innovate so you might hear some people talking about it. |
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.