It's all about the answers!

Ask a question

Accepting more than 2048 elements using RTC API


Morten Madsen (3052842) | asked Oct 30 '18, 8:01 a.m.
When I do the following command:
compareSource.accept(AcceptFlags.DEFAULT, sync.incomingChangeSets(), RTCAPI.getActiveRepository(), null);
    
I get the error:
java.lang.IllegalArgumentException: Item Handle array cannot exceed 2048 elements.
    
I figure I could loop and accept blocks of 2048 change-sets, but then I'll might encounter Gaps, so I'll have to use some re-try algorithm including the Gap change-sets.

Does anyone know if there's an easy way to just "Accept all" from a source workspace?

Maybe I should use:

com.ibm.team.filesystem.client.IOperationFactory.getWorkspaceUpdateOperation()

instead?

Accepted answer


permanent link
David Lafreniere (4.8k7) | answered Nov 01 '18, 10:38 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Note: It's generally rare to have to worry about accepting over 2048 change set (this means you are REALLY out of sync with your accept source). From an API standpoint, it's bad practice to allow 'open ended' operations to run, (such as accept everything, which could be thousands and thousands of change sets in theory, which would slow down the server). This is why most API always has a max limit, to allow clients to batch fetch as appropriate. So there is no alternative 'accept' method in this case.

The accept method has a AcceptFlags#PREFLIGHT flag, so you in theory could make sure the accept would work first, and if not, try a smaller subset (not an ideal solution as you pointed out).

Instead of performing an accept operation (for cases where you anticipate possibly more than 2048 change sets to accept), perhaps you could consider performing a component replace instead?

For your other question, you 'could' use: com.ibm.team.filesystem.client.IOperationFactory.getWorkspaceUpdateOperation()
This does have logic to do what you want. The only issue there is that officially, this filesystem client-side code is not API and is subject to change (although code in this area is changing far less frequently than it used to).
Morten Madsen selected this answer as the correct answer

Comments
Morten Madsen commented Nov 04 '18, 10:59 a.m.
Thanks a lot David. I'll try the solution with batches of 2048 and then scaling back until something works.

We are having many change-sets at the moment, because we are in the process of importing into RTC. So I guess this is a one-time thing. Though I want the automated RTC GUI (that we're building) to be able to handling these situations.

A component replace might not be appropriate, if the user has outgoing change-sets, but else I guess I could do that.

Your answer


Register or to post your answer.