So unfortunately this method apparently requires changesets to be in a particular order based on a TODO note in the javadoc:

* TODO: deliverCombined currently depends upon the order that change sets are presented.
* This restriction could be lifted if we were to be a bit more permissive w/gaps.

So far, we have had success with ordering the changesets to be delivered by their getLastChangeDate() value, oldest first in the array. Our server plugin delivers changesets as part of a work item save operation, and recently one of our customers hit this error:

CRRTC5042E: Cannot deliver changes since they would create conflicts for item '/foo/fubar.properties' in component 'Component 'FooComponent''. Try accepting all incoming changes, resolve the conflicts, then deliver again.

Their server version is 5.0.2.

They reproduced with the standalone Eclipse UI as well, trying to deliver the changeset that contains just that part causes the error, even though that part was not changed in any other outgoing or incoming changeset.  They worked around this be mass-delivering all outgoing objects (which, given the state of the stream, our tool would have effectively done as well).

Since the file in question was only changed once in a single changeset, there were no other incoming or outgoing changesets that should have either (A) prevented it from delivering in isolation, or (B) prevented all the other changesets from delivering without it.  Unless of course there is a bug with file highlighting in Pending Changes. So it is mysterious why RTC would throw this error for this file, and especially in our tool's case where we *were* delivering all outgoing changesets.

Are there any gotchas involved with deliverCombined() that developers need to be aware of?  In our case we are only passing an array of IChangeSetHandles, the IBaselineHandle array is empty.  Could not delivering outgoing baselines cause this problem?  Is there something else we should be ordering the changeset list on instead of the last changed date?