It's all about the answers!

Ask a question

Issue with retrieving the time a changeset entered a stream when used in conjunction with a specific promotion method.


0
1
Thomas Hopkins (1111) | asked Oct 08 '13, 4:10 a.m.
edited Oct 08 '13, 7:57 p.m. by Millard Ellingsworth (2.5k12431)

Currently I am trying to create a tool which can be used to track how long changesets take between being delivered between streams in RTC V4.0.3. It works by getting a list of all the streams used, and getting a list of all the components used by that stream. It then gets the IChangeHistory for each IComponentHandle, and then for each IChangeHistoryEntryChange it gets the IChangeSetHandle involved. From this it can call .creationDate() to find out when this changeset entered this particular stream (in theory).

Whilst this works correctly for my own team's set of streams, it does not work for another teams set of streams in a different RTC project. I believe I have correctly updated all of the sign in and connection info as it does return information about their changesets. However the issue is that for a changeset it records the time it entered a stream as the same exact time for all streams that particular changeset entered, e.g. streams 1, 2 and 3 would all have the exact same entry time.

The second team does use a different method of delivery whereby a changeset is delivered to a temporary workspace before being delivered to the target stream destination. I have tried to recreate this within my own teams Sandpit repository and it did still function correctly, however I used a permanently created Workspace rather than their temporary method.

I was just posting this incase anyone had any suggestions or input they could offer which may shed some light on the issue of why it doesn't work in the second case.

Thanks for any help you can offer.


2 answers



permanent link
Andrew Niefer (7135) | answered Jun 10 '14, 3:58 p.m.
JAZZ DEVELOPER
In RTC 4.x and earlier, IChangeHistoryEntry.creationDate and IChangeHistoryEntry.createdBy are the time and contributor for when that ChangeSet was added to that IChangeHistory.  IChangeHistory objects can be shared between streams by delivering baselines.

If you are always accepting/delivering only changeSets then this will be the time that the changeSet was introduced to the stream that you got the IChangeHistory from.

If you create a baseline in your workspace and deliver that baseline to a stream, then you are sharing your workspace's IChangeHistory object with the stream.   So, the stream -> changeHistory -> changeHistoryEntry is the one from when you accepted the change into your workspace.

Starting in 5.0.1 Sprint 1 which will be available in the next week or so, Story 304215 introduces changes so that when you use IWorkspaceConnection.changeHistory(), the IChangeHistory.recent, getHistoryDescriptor and getHistoryDescriptors will return the dates the changeSet was actually introduced to that stream regardless of whether or not baselines were used.

permanent link
Tim Mok (6.6k38) | answered Oct 09 '13, 8:56 a.m.
JAZZ DEVELOPER
The information that you want is not currently recorded. The creation date is the date the change set was created and has no relation to when the change set was delivered.

See https://jazz.net/forum/questions/95403/how-can-one-find-the-delivered-date-of-a-change-set

Comments
Thomas Hopkins commented Oct 09 '13, 9:40 a.m.

Thanks for the reply, sorry for not being clear but I am calling .creationDate() on the IChangeHistoryEntryChange and am getting different times for the same changeset in stream 1 and 2, the times appeared to be correct when I tested it by promoting changesets through the system but perhaps this is not correct.

Could you clarify what is meant to be returned for the creationDate() for a IChangeHistoryEntryChange? I was also wondering what exactly creates an IChangeHistoryEntryChange (for example would a comment change to a changeset  create an entry)?

Your answer


Register or 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.