It's all about the answers!

Ask a question

Creating new file without commiting it to a changeset using Java API

Mike Polan (2234) | asked Mar 16 '15, 1:27 p.m.
Hey everyone,

Using the RTC Java API, I want to create a new file, tell my sandbox about it, and have it be considered a "local change" ("Unresolved" using Eclipse terminology) until I decide to package it up in a changeset. I have the following snippet I put together from the examples, but for some reason, the LocalChangeManager is not recognizing my new file (it does recognize files that were modified and deleted though). I have a suspicion that I'm missing something simple, but the javadoc is not clear on this case.

Any ideas? Thanks!
// Create a new file and give it some content
IFileItem file = (IFileItem) IFileItem.ITEM_TYPE.createItem();


// Refresh the sandbox and pick up any changes to our files
ILocalChangeManager lcm = FileSystemCore.getSharingManager().getLocalChangeManager();
lcm.refreshChanges(new ISandbox[] {sandbox}, RefreshType.TRAVERSE_ALL_WITH_RECOMPUTE_OF_KNOWN, null);

// !!! But the changes array does not contain the file I just added !!!
ILocalChange[] changes = lcm.getPendingChanges(workspaceConnection.getContextHandle(), component, sandbox));

Accepted answer

permanent link
Evan Hughes (2.4k1318) | answered Mar 17 '15, 11:16 a.m.
IConfigurationOpFactory is used to update a repository workspace by adding changes to a change set. The usage pattern is to get a workspace connection, create a bunch of save operations, then run IWorkspaceConnection#commit() on those ops. Calling save() without committing the change drops the op onto the stack for the garbage collector to gobble up. ;)

If you want to change your sandbox, I suggest that you write the file with your preferred method: if you're running outside of Eclipse use, or, if you're writing a plugin that runs inside Eclipse, use the resource layer. If you're using the approach, hit Eclipse with the big hammer: lcm.refreshChanges(TRAVERSE_ALL_WITH_RECOMPUTE_OF_KNOWN). I say "big hammer" because that will walk the entire filesystem under the sandbox. You can get better performance by refreshing the parent of the file you've added. 
Mike Polan selected this answer as the correct answer

Stefano Antoniazzi commented May 09 '16, 6:20 a.m.

 Note that for some reasons there are no pending changes without a  

as written in local-changes-deliver

One other answer

permanent link
Stefano Antoniazzi (1701711) | answered May 09 '16, 5:27 a.m.
edited May 10 '16, 10:18 a.m.
This is really interesting but would point out that there's something else to take care about.

Everything works fine if you make a simple sequence:
  • load a repository workspace in a filesystem
  • make a change (add a file or change the content of a file)
  • try to get local changes using plain java api (after a  sandbox.allShares(null); )
but if you try again only to get local changes using plain java api  (without loading the workspace again) you could get some exceptions related to

I've seen that this situation follows the presence of a .isCorrupt file on the metadata and this file is created after the  sandbox.allShares(progressMonitor) that I needed to get local changes.

Reading this post from Evan I understood that the problem arise if you don't deregister the sandbox after a prior operation.

So I fixed adding a final sharingManager.deregister(sandbox, progressMonitor); after the load operation and at the and of other operations that write a .jazzlock file.

Maybe Evan could also explain the reason :-) ....

Your answer

Register or to post your answer.