It's all about the answers!

Ask a question

Java API extending - current change set displays last change set assets


Peter Moraza (331723) | asked Oct 24 '13, 9:19 p.m.
retagged Dec 16 '13, 4:13 p.m. by David Lafreniere (4.3k7)
Hi,

I am experiencing the following issue using the RTC 4.0.2 Java API. First, I deliver a project (folder structures and files) to the repository with a change set comment. It displays correctly in the Repository Files view in the Jazz Admin perspective. I then move a subfolder and file within that project and deliver that update to the repository. The moved subfolder and file display correctly in the Repository Files view, but the issue is that the moved subfolder and file also display in their original location, as if I did a copy and not a move. And if I delete a previously delivered file and update the project using the API the file still appears in the current change set.

If I repeat the same actions and perform the deliver using the RTC client then the dir/file moves and deletions display correctly.

My API code merely discovers the repoPath of each dir and file under the project parent dir and passes it to iconfig.resolvePath to discover if it exists or not in the component, then does creation or update based on the state of filePathHandle.

IVersionableHandle filePathHandle = iconfig.resolvePath(cmpntroot, repoPath, monitor);

Do I also need to discover what exists on the component side and delete on the component side if it does not exist in the current package I am delivering? Or is there some property I can set which specifies to not include earlier change set revisions in the latest change set I am delivering? Thanks in advance!

Peter


Comments
Remy Suen commented Oct 29 '13, 10:55 a.m.

I think it would be better if you provided more of your code. It's not clear how you're moving the files and folders at the moment.


Peter Moraza commented Oct 29 '13, 5:08 p.m.

Hi Remy, I will copy the relevant code here, but first want to more graphically illustrate the issue.


First delivery looks like this in stream:
ProjectRootFolder
   Subdir01
      file01.dat
   Subdir02
      file02.dat
   Subdir03
      file03.dat

I then move Subdir03 and it's file under Subdir02 and deliver, but this is how it looks in stream after delivery:
ProjectRootFolder
   Subdir01
      file01.dat
   Subdir02
      Subdir03
         file03.dat
      file02.dat
   Subdir03
      file03.dat


Peter Moraza commented Nov 04 '13, 8:42 p.m.

Hi Remy,

I'm working primarily with Eclipse projects, and the move (or deletion) of directories and files is being done manually in the Eclipse toolkit. The structure is good in the Eclipse toolkit, but delivering that new change set using the Java API includes the directories and files that existed in all the previous change sets. If I load my Eclipse project with the change set just delivered to RTC then I get an accumulation of all my earlier change sets. We need to use the Java API because we are migrating a huge set of projects from our current repository to RTC.
Peter


Peter Moraza commented Nov 04 '13, 9:07 p.m.

Here is the code delivering the change sets to RTC.


IChangeSetHandle cs1 = wkspccnctn.createChangeSet(cmpnthndl, monitor);
IConfiguration iconfig = (IConfiguration) wkspccnctn.configuration(cmpnthndl);
IFolder cmpntroot = (IFolder) iconfig.rootFolderHandle(monitor);
IFolder cmpntcurrent = cmpntroot;
String comment = stcomment;
SCMPlatform.getWorkspaceManager(repo).setComment(cs1, comment, monitor);

deliverPackageToStream(repo, cmpnthndl, wkspccnctn, cs1, iconfig, cmpntroot, cmpntcurrent, srcroot, new File(srcroot), monitor);

IChangeHistorySyncReport sync = 
wkspccnctn.compareTo(strmcnctn, WorkspaceComparisonFlags.CHANGE_SET_COMPARISON_ONLY, Collections.EMPTY_LIST, monitor);
wkspccnctn.deliver(strmcnctn, sync, Collections.EMPTY_LIST, sync.outgoingChangeSets(cmpnthndl), monitor);
monitor.subTask("Created change set and delivered to " + strmcnctn.getName());


Peter Moraza commented Nov 04 '13, 9:20 p.m.

Hi,


I'm unsure about the properties I'm setting in these two lines of code. I want to deliver the current project so that it's change set only contains the current project, not folders and/or files that existed in earlier change sets and no longer exist. Anyone see anything I need to change here?

IChangeHistorySyncReport sync = 
wkspccnctn.compareTo(strmcnctn, WorkspaceComparisonFlags.CHANGE_SET_COMPARISON_ONLY, Collections.EMPTY_LIST, monitor);
wkspccnctn.deliver(strmcnctn, sync, Collections.EMPTY_LIST, sync.outgoingChangeSets(cmpnthndl), monitor); 


Remy Suen commented Nov 05 '13, 8:35 a.m.

When change sets build on top of each other, you cannot just randomly deliver a subset of them as it creates a gap. If you say the changes look fine on disk then it seems like the way you are creating the change sets to move your files and folders is incorrect.


Ralph Schoon commented Nov 05 '13, 9:42 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

I haven't found how to move files, but as described here: https://rsjazz.wordpress.com/2013/09/30/delivering-change-sets-and-baselines-to-a-stream-using-the-plain-java-client-libraries/ you have to be careful what you do with the API. You can easily use the API and upload the same content again. If you move files, I assume there is some kind of rename capability. If you just upload the files at a different place, you just create a new copy. At least you would have to delete the old file, to avoid duplicates. However, to preserve the history, I would assume there is something like a move or rename capability in the API.


Peter Moraza commented Nov 06 '13, 9:51 p.m.

I was testing delivering Eclipse sandbox (on local machine) moves and deletions when I encountered this behavior. I am not trying to move or delete files in the repo workspace and not make those changes locally. I just want to deliver everything in my Eclipse sandbox (on local machine) to the stream and have my Eclipse sandbox (on local machine) accurately depicted there. Sorry I cannot paste .jpg images, but I lack the reputation points to do so. I'll read the rsjazz link and comment further later. Thanks for all your input so far!


showing 5 of 8 show 3 more comments

Accepted answer


permanent link
Peter Moraza (331723) | answered May 29 '14, 4:42 p.m.
Hi,

Because our development process rarely imposes changes to our workspace structure, this turned out not to be an issue after all. Our mass migration to RTC was done successfully with no issues encountered. Thanks!

Peter

Ralph Schoon selected this answer as the correct answer

Your answer


Register or to post your answer.