search for changesets delivered during a specific timeframe
Andrew Pham (21●1●1)
| asked Sep 21 '11, 5:53 p.m.
retagged Jun 09 '14, 10:56 a.m. by David Lafreniere (4.8k●7)
Hi,
I've been trying to find out a way to look for changesets delivered during a specific timeframe, e.g. the last 12 hours. I found that creating snapshots is one way to do this but trying to find a less invasive way (like without having to create and checkin stuff). I've been looking around a bit but haven't found anything yet. Be able to do this with a query would be nice but it seems like query is for work items mostly. The whole purpose of this is for debugging when someone delivered code that caused a regression. Being able to list all the changesets since the last successful execution would help pin point the culprit quicker. Thanks, Andy |
12 answers
The whole purpose of this is for debugging when someone delivered code that caused a regression. Being able to list all the changesets since the last successful execution would help pin point the culprit quicker. The following feature added in Story 304215 (https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/304215) may help a little bit with what you are trying to achieve. This story will provide "Added By" and "Date Added" columns to the History view in Eclipse and Visual Studio, as well as the corresponding CLI commands. This Story has been completed for RTC 5.0.1 Sprint 1. See the following wiki for UI screenshots of this feature: https://jazz.net/wiki/bin/view/Main/AddedByInfoInHistoryView. This doesn't directly solve what you are trying to achieve, but can help you quickly see when change sets were added to a stream and who added them (this is assuming you know which stream/component/change sets you are interested in). |
The change set search cannot specify a time window when they were delivered to the stream. It can only check the change set creation date. I would recommend the best practice to be using the JBE to perform the builds. It creates snapshots of each build. When testing the build and finding a defect, the build snapshot can be compared to the last known good build to determine the changes. For any other use case, an enhancement work item will be necessary since there is no current way to retrieve all delivered change sets in the past X hours. I'm OK with post processing the results from a change set search and in fact might be better. Would be fairly trivial to iterate thru the list and capture the change sets between two build entries. However, I not aware on how to craft a similar query programmatically. (preferably via the OSLC REST interface) ICSW Team Default Component |
Actually looking back at event log again it seems promising. Once you filter it down to just showing source control changes. Wondering if the following would be of help: Search -> Jazz Source Control -> Change sets... Anyone know how to programmatically issue those searches?The change set search cannot specify a time window when they were delivered to the stream. It can only check the change set creation date. I would recommend the best practice to be using the JBE to perform the builds. It creates snapshots of each build. When testing the build and finding a defect, the build snapshot can be compared to the last known good build to determine the changes. For any other use case, an enhancement work item will be necessary since there is no current way to retrieve all delivered change sets in the past X hours. |
Actually looking back at event log again it seems promising. Once you filter it down to just showing source control changes. Wondering if the following would be of help: Search -> Jazz Source Control -> Change sets... Anyone know how to programmatically issue those searches? |
Actually looking back at event log again it seems promising. Once you filter it down to just showing source control changes.
Team Dashboard -> configure -> Filters -> Source Control Changes Though it doesn't seem to allow specifying a timeframe but it will work for me for now. History is kept on a per-component basis, so you'd have to open up the I was looking around in RTC but didn't find anything like that. |
If you run daily builds with JBE, you can compare builds that will show you differences.
|
Yeah our source has quite a number of components and we're under a very active development cycle with changes coming from all over the places. Sounded like, using snapshot would be the best solution in this scenario wouldn't everyone agree?
Thanks all for very helpful inputs. Andy History is kept on a per-component basis, so you'd have to open up the I was looking around in RTC but didn't find anything like that. |
Geoffrey Clemm (30.1k●3●30●35)
| answered Sep 23 '11, 12:25 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
History is kept on a per-component basis, so you'd have to open up the
stream folder, and under it, you would see entries for each component in the stream. Right click on any of those component entries, and you'll get the change-set history of that component in that stream. But if you don't have an idea about what component you want to look at, and you have a large number of components in the stream, then this would be cumbersome. Cheers, Geoff On 9/22/2011 9:53 AM, apham wrote: I was looking around in RTC but didn't find anything like that. |
sounds more and more like creating snapshots is the only solution.
There's nothing quite suitable for you to search for change sets delivered to a stream in the past 12 hours. You can show history on a component but not for the entire stream. There are also stream events that would show change set deliveries but I think events disappear at some point (maybe when you've read them or accepted the changes). |
There's nothing quite suitable for you to search for change sets delivered to a stream in the past 12 hours. You can show history on a component but not for the entire stream. There are also stream events that would show change set deliveries but I think events disappear at some point (maybe when you've read them or accepted the changes).
|
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.