How to get full path from changeset for files that were added and deleted?
Hey everyone,
I've stumbled into another issue trying to get the path to a file or folder in a changeset using the RTC 4.x Java API. Let's say that a changeset contains a series of folders that were added, and the last folder has an added file in it. Something like this (also applies when the hierarchy was deleted instead):
+ /folder1
+ /folder1/folder2
+ /folder1/folder2/MyFile.txt
For example, I would now like to build the full path to MyFile.txt using the data from its IChange object that came from the containing IChangeSet.
I originally used IConfiguration.locateAncestors like this poster did, and that seemed to work fine for changeset files that were not under newly deleted/added folders. However, in the latter case, that method call always returned an empty list of ancestors.
I also tried walking the IVersionable hierarchy using IVersionable.getParent (see bottom of the thread). This also works for the first case in the previous attempt, but once again, in my scenario IVersionable.getParent() returns an item with no state ID, and therefore trying to fetch it to continue building the path results in an exception.
Whenever an IConfiguration object was needed in the above methods, I got an instance of it from my workspace's accept flow target (from the IFlowTable). I suppose this issue is because the parent of such an item (MyFile.txt) was either just added as part of this changeset, or it was just removed.
So, how would one achieve the results I'm shooting for? What I'm getting at is to make a hierarchy of changed files per changeset, somewhat like the "Pending Changes" view in the RTC Eclipse client does.
Thanks!
I've stumbled into another issue trying to get the path to a file or folder in a changeset using the RTC 4.x Java API. Let's say that a changeset contains a series of folders that were added, and the last folder has an added file in it. Something like this (also applies when the hierarchy was deleted instead):
+ /folder1
+ /folder1/folder2
+ /folder1/folder2/MyFile.txt
For example, I would now like to build the full path to MyFile.txt using the data from its IChange object that came from the containing IChangeSet.
I originally used IConfiguration.locateAncestors like this poster did, and that seemed to work fine for changeset files that were not under newly deleted/added folders. However, in the latter case, that method call always returned an empty list of ancestors.
I also tried walking the IVersionable hierarchy using IVersionable.getParent (see bottom of the thread). This also works for the first case in the previous attempt, but once again, in my scenario IVersionable.getParent() returns an item with no state ID, and therefore trying to fetch it to continue building the path results in an exception.
Whenever an IConfiguration object was needed in the above methods, I got an instance of it from my workspace's accept flow target (from the IFlowTable). I suppose this issue is because the parent of such an item (MyFile.txt) was either just added as part of this changeset, or it was just removed.
So, how would one achieve the results I'm shooting for? What I'm getting at is to make a hierarchy of changed files per changeset, somewhat like the "Pending Changes" view in the RTC Eclipse client does.
Thanks!
Accepted answer
A file in a change set does not have a path ... because the path is generated from the parent folders of that file, and a file only knows its immediate parent. The other parents must be determined from a configuration (stream, workspace, baseline). The pending changes top level entries are always streams or workspaces, and the paths you see in the pending changes entries are derived from that stream/workspace context.
Comments
Thanks for the feedback, based on the other posts on this forum I understand that's the approach I'll have to take. I guess the question is, what to do when IVersionable.getParent() returns a parent that does not have a state ID? How can I continue further up the hierarchy to continue building the path to the item in question?
Never mind, turns out I was overthinking it. :) Using a combination of IConfiguration.locateAncesors() and IConfiguration.determineAncenstorsInHistory() did the trick.
Hi, Mike, could you help to public your code of using a combination of locateAncestors() and determineAncestorsInHistory()?