List all changesets in component in stream
Hi all,
2 answers
Comments
Hi Luca,
Actually, I didn't retrieve the "date added" of the change set.
Instead, I retrieved the date of each change (i.e. each changed file) in the change set.
IFileItem fileItem = (IFileItem) versionable;
// get change date
DateFormat dateFormat1 = new SimpleDateFormat("MM/dd/yyy");
DateFormat dateFormat2 = new SimpleDateFormat("HH");
Date changeDate = fileItem.getFileTimestamp();
String changeDateS = dateFormat1.format(changeDate);
String changeHourS = dateFormat2.format(changeDate);
if(changeDateS.equals("01/01/1970")){
changeDate = cs.getLastChangeDate();
changeDateS = dateFormat1.format(changeDate);
changeHourS = dateFormat2.format(changeDate);
}
String changeDateSort = changeDateS.substring(6,10)+changeDateS.substring(0,2)+changeDateS.substring(3,5)+changeHourS;
LQE together with Report Builder can do this out of the box.
Comments
My understanding is that this information is not posted to the LQE index. Do you have some documentation or personal experience that it is?
I have V.6.0.4 and can do a report with LQE datasource based on SCM Changesets.
In traceability you can see the linked work item:
On the changeset you have some attributes like components,number of changed files etc.
Important: You need to have the TRS datasources enabled in LQE for SCM, not only CCM.
regards
Guido
See also News and Noteworthy of RTC 6.0.3
Yes, some information about change sets is stored in the LQE, but the question was about listing all of the change sets in a given stream in a given component. I didn't see any "stream" information associated with the change sets, so how would one produce a report that only listed the change sets in a given stream?
Your right. Sorry I missed this requirement.
Also merging with the Stream Artifact does NOT give any information more (see below).
(Btw. it's silly but this gives stream information's from RM and not CCM).
Maybe we should bring Ernest or Rafik into this discussion. The use case is very valid.
regards
Guido
We definitely want to get this kind of information into the LQE index, but because of the volume for this kind of data (for example, a simple, very fast deliver operation could logically add thousands of change sets to a stream), one has to be careful how the data is modeled in the index, or be able to quickly handle massive amounts of new data. The re-architecture of the LQE index currently underway may allow us to use the latter approach, but we'd want to verify that.