It's all about the answers!

Ask a question

Get data displayed in Pending changes view via API


Gidi Gal (861529) | asked Jul 26 '16, 11:06 a.m.
edited Jul 31 '16, 12:25 p.m. by David Lafreniere (4.4k7)
Hello,

I'm trying to gather all API required to find about status of a file in Pending changes view:

1) Is it unresolved ? I understand  ILocalChangeManager is the required API.
https://jazz.net/forum/questions/44421/api-to-determine-local-not-checked-in-changes
2) Does it collide with incoming change-set or already require merge ?
3) Is it in incoming change-set ?
4) Is it in outgoing change-set ?
5) Is it locked ?

Also, I'd like to listen to events that change this status, if you have pointers for relevant listeners (currently I know of IConfigurationUpdateEvent.CONFIGURATION_UPDATED, It does not cover all the scenarios) it would be great if you can share them here.

Thanks,
Gidi

Accepted answer


permanent link
David Lafreniere (4.4k7) | answered Jul 31 '16, 12:41 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
Note: Most of the SCM client side code is not considered API and is internal. Take a look through the 'com.ibm.team.filesystem.client' package to get an idea of some of the things that are available to you.
The Pending Changes view and most of the 'things' it uses is also internal. You could use some of it, but keep in mind it is subject to change with any release, or you could take a look at the code for ideas.
The Pending Changes view model is ComponentSyncModel, and a particular component node in the PC view is a ComponentSyncContext. The PC view listens to many events in a class called EventManager (ex: Events in IFlowNodeConnection, IChangeHistoryEvent, IActiveWorkspaceManager, etc.). Logic related to locked files is managed in UserLockCacheManager and UserLockCache.
Gidi Gal selected this answer as the correct answer

Comments
Gidi Gal commented Aug 01 '16, 9:03 a.m.

Hello David,
Many thanks for your reply. I have one more question regarding the initialization of the  PC view (when RTC is launched and user performs log-in)- is there an event triggered when the initialization is done and all data in the ComponentSyncModel is updated ? I understand I will need a much better listening mechanism to monitor all the events in EventManager. I am hoping to start my information gathering from a scenario where the initialization is done and then improve it with additional listeners.
Is it IComponentSyncModel.WORKSPACE_SYNC_CONTEXTS ?
Thanks,
Gidi


David Lafreniere commented Aug 08 '16, 1:00 p.m. | edited Aug 08 '16, 1:03 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

I don't believe there's a nice easy way to tell when 'initialization' is done. ComponentSyncModel.getInstance() will start the singleton instance, as well as start up other 'manager' (if they have not started already). From there as mentioned above, things are updated in the UI after responding to various events (which come in asynchronously from the different managers and other places...) So there is no real well defined state of 'initialization is done'.

The Pending Changes view code, as you are seeing, is our most 'complex' piece of code in Jazz SCM, with many levels of interaction, all built up over ~9 years...


David Lafreniere commented Aug 08 '16, 1:10 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

If I recall correctly though. Listening to IUpdateManager.UPDATE_STATUS_COMPLETED would be when the PC view is refreshed... (so hopefully this gets sent out early when things start up and should be roughly initialized).

This can be added like this:

<code>final IListener tracksUpdateManagerListener = new IListener() {
   public void handleEvents(List events) {
   // do what you want here...
   }
};

FileSystemResourcesPlugin.getComponentSyncModel().getUpdateManager().addGenericListener(IUpdateManager.UPDATE_STATUS_COMPLETED, tracksUpdateManagerListener);</code>


Gidi Gal commented Aug 24 '16, 9:44 a.m.

Hello David,
Thanks for your reply. I'm currently testing the behavior of UPDATE_STATUS_COMPLETED, I see it is called once before the user log-in with the operation string CONTEXT_REFRESH_COMPARE_NOTIFY_ACCEPT_OPERATION
and twice after the log-in with the string
CONTEXT_REFRESH_SUSPEND_OPERATION
I can filter the calls to focus on CONTEXT_REFRESH_SUSPEND_OPERATION and add a flag in order not to call twice my initialization code. If there's a way to distinguish between the two calls after the log-in is performed I'll be grateful if you share it here.
Thanks,
Gidi


Gidi Gal commented Aug 24 '16, 10:55 a.m.

Hello David,
An update: When I use the second call after log-in (CONTEXT_REFRESH_SUSPEND_OPERATION )the call to IComponentSyncModel.getWorkspaceSyncContexts() returns 0 elements, so I cannot track the status of elements in the model.
Best regards,
Gidi


David Lafreniere commented Nov 08 '16, 11:48 a.m.
FORUM MODERATOR / JAZZ DEVELOPER

I guess when the PC view first starts up there are no workspaces tracked, and they come in asynchronously via events later on.

Perhaps try something like:
IActiveWorkspaceManager manager = FileSystemResourcesPlugin.getActiveWorkspaceManager();
manager.addGenericListener(IActiveWorkspaceManager.ACTIVE_WORKSPACES, myIListener);
I suspect this would be the event that is sent when the list of active workspaces changes...

I think the PC view might respond to this event in EventManager and request a refresh of the PC view which would later show the nodes in the UI. The PC view would do this using this code:

if (pce.getProperty().equals(IActiveWorkspaceManager.ACTIVE_WORKSPACES)) {
   updateManager.requestModelUpdate(COMPONENT_SYNC_MANAGER_UPDATE_OPERATION);
   continue;
}

showing 5 of 6 show 1 more comments

Your answer


Register or to post your answer.