We do not make it easy for you to find a workspace which references this change set, at least by using API. There are ways to do it under the covers, but it has not been exposed as API as of yet. I have raised a work item at https://jazz.net/jazz/resource/itemName/com.ibm.team.workitem.WorkItem/152190 to track this.

There is a hint that is often useful (but not necessarily always correct), hidden in the ILink which serves as the binding between the IChangeSetHandle (source) and the IWorkItemHandle (target).
The IItemReference for the source side has a String extraInfo field which can be retrieved via IItemReference#getExtraInfo(). This string will be of the format IWorkspace=<UUID> which indicates the originating workspace. You can create a handle to the IWorkspace by using IWorkspace.ITEM_TYPE.createItemHandle(suppliedUUID, null).

This workspace many have moved on and discarded this change set from its history. Additionally, the workspace may have been deleted after the link was created. But often this "hint" is good enough for interpretting the change set with respect to paths.

Note that a change set is a free-standing object (i.e. is not inherently
linked to any particular configuration). John's responses provide ways
of finding some configuration that would give you "a path", but there is
no such things as "the path" for a file in a change set.

Cheers,
Geoff

On 1/31/2011 10:08 PM, crvich wrote:

I have an IChangeSet retrieved from an IWorkItem. I can get the
IFileItem from this without a problem. However, in order to get the
full path to the file, I need an IConfiguration object so I can use
locateAncestors() or determineAncestorsInHistory().

Presumably this would come from the IWorkspace (or rather the
IWorkspaceConnection for that workspace) that the IChangeSet is
associated with.

So I guess the real question might be...how do I obtain the workspace
associated with a changeset?

Gentlemens,

I have the same problem...find the path to a related ChangeSet File.
The View "Pending changes" is able to display the path.

Any solution to this problem?
Thanks in advance

Stefan

Hi,

sometimes the solution is just in front of us...I found the solution with IscmService#configurationLocateAncestors.
After that I recognized that there is still a good example... the "advisor example" https://jazz.net/wiki/bin/viewfile/Main/RTCSDK20_ProcessPreConditionExample?rev=2;filename=advisor-example.zip

Note that this method takes as an argument the configuration in which
the files/folders are to be given names. So even if you had a
client-side variant of this method (which probably does exist) it does
not provide a way to get a configuration from a change set.

The only way to do so is to lookup the "creating workspace" annotation
on the change-set, which will give you a configuration if that
annotation was created, and if that workspace still exists. (Perhaps
someone on this forum knows how to query for that information?).

Cheers,
Geoff

On 2/14/2011 6:23 PM, crvich wrote:

shufnaglwrote:
I found the solution with IscmService#configurationLocateAncestors.

This appears to be intended for server-side code, whereas my situation
is purely client-side.

To understand why a file/folder in an RTC change set can be given a
pathname only in the context of a configuration, think of the simple
case where a change set modifies a single file, "foo.txt".
You have two workspaces, one in which that file is in a folder named "x"
and the other in which that file is in a folder named "y".
In the first workspace, the pathname of the file is .../x/foo.txt.
In the second workspace, the pathname of the file is .../y/foo.txt.

So given just the change-set, what is the pathname of the modified file?
The answer is, you don't know.

WRT the GUI example, the GUI shows full pathnames for a change set only
by selecting some configuration.

In some cases, the particular view you are using in the GUI implies a
configuration (for example, when the GUI displays a change-set in the
history of some workspace or stream, it uses the current configuration
of the workspace/stream to give the members of that change set pathnames.

In other cases, the workspace in which a change-set is created is
associated with the change-set. In those cases, the system can lookup
that workspace (if it hasn't been deleted), and use that to show
pathnames for the files/folders. But note that those pathnames may be
completely different from those that you see when you accept that
change-set into some workspace ... since it is the configuration of the
workspace that determines the pathnames of files/folders in that workspace.

Cheers,
Geoff

On 2/7/2011 6:38 PM, crvich wrote:

gmclemmwrote:
Note that a change set is a free-standing there is no such things as
"the path" for a file in a change set.


I'm not sure I understand this. If you move a Java source file to a
different package and check in the changes (but don't deliver or
create a new baseline), the RTC GUI is able to show the old path and
the new path to the user. So this info is clearly known, and is
critical to our tool (or at least the new path is). The API doesn't
provide a reliable way to retrieve this?