It's all about the answers!

Ask a question

ImmutablePropertyException on file

N. VD (842634) | asked Feb 05 '15, 10:51 a.m.
retagged Feb 05 '15, 11:24 a.m. by Evan Hughes (2.4k1318)

When i try to change an IFileItem, i get the ImmutablePropertyException.
I have found some posts on the forum to work with a workingcopy of the file, so i did.
but  the change i make to the workingcopy does not get applied into the stream...
(i'm extending the delivery process)

fileItemCopy.setUserProperty(PROPERTY, definition_UUID);	
// change not applied in the stream
fileItem.setUserProperty(PROPERTY, definition_UUID); // throws ImmutablePropertyException

One answer

permanent link
Evan Hughes (2.4k1318) | answered Feb 05 '15, 11:23 a.m.
edited Feb 05 '15, 11:24 a.m.
Are you dealing with an IWorkspace that the user has loaded into a sandbox, or are you manipulating a repository workspace by fiddling with the server? 

If you're working with a loaded repository workspace that has been loaded into the sandbox, you should make your changes locally by:
  1. getting an IShareable for the file you care about,
  2. grabbing the user properties from the shareable with getMetadataProperties() ,
  3. modify the properties,
  4. run IOperationFactory.instance.getChangePropertiesOperation() to get an object that's capable of saving your modifications
  5. use IChangePropertiesOperation#setProperties() followed by run() to update the local metadata
After doing that, you'll have a pending change that can be committed.

On the other hand, if you're directly manipulating an unloaded repository workspace, you can create a change set to record your changes directly. To do that using the client libraries (ie, an IWorkspaceConnection ):
  1. Modify the IFileItem working copy as you're doing today,
  2. call wsConn.configurationOpFactory() on your workspace connection to get the op factory,
  3. call to create the save operation that you want to commit,
  4. call wsConn.commit() on the save operation from the previous step.
After doing that, you'll have an outgoing change set in your repository workspace that you can flow to the stream.
You can commit with the server APIs by calling IScmService directly, which is roughly analogous to using the client libraries. The difference being that you call IScmService#batchCommit() to commit.

N. VD commented Feb 05 '15, 3:21 p.m.


thanks for putting the effort in answering the question in such a clear way.
Does this also apply for a server-side advisor?
I'm using a delivery advisor to change a specific userproperty on this file directly in the changeset that is getting deliverd into the stream.

Evan Hughes commented Feb 05 '15, 4:35 p.m.
I'm using a delivery advisor to change a specific userproperty on this file directly in the changeset that is getting deliverd into the stream.

I don't recommend modifying change sets while the advisor is running, since advisors aren't supposed to modify their arguments. Additionally, the change sets that are being delivered may be closed, so your changes may end up creating a new change set that isn't one of the delivery arguments. I'm not sure what will happen in that scenario. :)

(Okay, I have an idea of what will happen: exceptions)

Have you looked at follow-up actions? I believe they are intended to allow modifications to data. I don't have a lot of experience with them, so I can't say whether or not there are gotchas you'll have to worry about. 

N. VD commented Feb 05 '15, 4:52 p.m.

Evan, thanks for the clear explanation.

Thanks for the tip about follow-up actionsm i'll look into that.

N. VD commented Feb 06 '15, 9:20 a.m.

  IScmService#batchCommit(), as u stated gives me this error:

Illegal operation ('commit') for stream 'MyLifecycleProject (Change Management) Stream'

I only have the target workspace available in my delta. (and that's the stream i suppose)

Evan Hughes commented Feb 06 '15, 1:22 p.m.

 Sorry - that completely slipped my mind: change sets can't be created or committed to on a stream (that's an IWorkspace with the 'stream' bit set). Instead you need to create the change sets on another workspace and deliver them. 

The usual pattern for working with process in RTC is that you create an advisor that enforces some constraint (such as requiring a specific property) and prevents users from delivering to a stream unless that constraint is met. Then you provide client-side tooling that makes it easy for the user to make the appropriate changes. For example, the Eclipse UI provides a bunch of quick fixes for process failures in the Team Advisor view. 

Your answer

Register or to post 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.