Getting file (versionable) history using Server Java API
![]()
(EDITED 2017-05-15 18:38 CET)
Hi,
I'm building a followup action to SaveChangeSetLink (IOperationParticipant).
Put simply I want to find the parent change set of a versionable (that is, a change set that includes the parent of my Versionable)
The end goal is to automatically create a "Blocked by" relation to other work items, that are linked to parent change sets. In this way, we can easily see what work items would create gaps in our stream, should we decide to promote these. It makes our deployment planning a lot easier.
I have tried this in two ways. Firstly I've tried to get the change set history of my versionable by using the following method:
ChangeHistoryEntry[] com.ibm.team.scm.common.IScmService.getHistoryForVersionable(ServiceHistoryProvider historyProvider, IVersionableHandle versionableHandle, int limit, boolean examineEras, ISynchronizationTimes[] syncTimes, IRepositoryProgressMonitorHandle monitor) throws TeamRepositoryException
But I'm getting the exception in the ccm.log:
java.lang.IllegalStateException: Illegal transaction in progress for service method call.
I can see in the documentation, that "You cannot call this method within a transaction", so I guess that is my problem. Does anyone know of any other method?
I've also tried to find the parent Versionable and then use the IScmQueryService to fire off a ChangeSetSearchCriteria, but I'm also getting the "transaction error" once again. I cannot call this service during a transaction.
Any ideas how I can go about this?
Thanks all,
/Morten.
|
Accepted answer
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.
Comments
I actually got it to work "somewhat" by using:
Sorry, never tried that. It might be impossible as you are blocking the DB for everyone else in the follow up action and that might be a long operation.
There is also no information what you want to achieve and why, so it is unlikely that others can come up with reasonable suggestions.
Thanks Ralph. I've just clarified my question a bit.
According to the error message, it looks as if the extension point basically does not allow such a long running operation within the context of a protecting transaction.