It's all about the answers!

Ask a question

How to get old path of moved file using java client API.

vikrant kamble (1323596) | asked Dec 29 '15, 4:39 a.m.
 Hi All,
I am following link. In example 3 in that link there is scenario that
User B adds files to folder and delivers it to stream. This changes are reflected as incoming changes to User A.
Following are steps I have been doing
User A and User B loaded repository workspaces and all components. There are 2 folders Folder1 and Folder2.
User B adds file NTD.txt to Folder1 and delivers it to stream.
To deliver this change set to stream User B associates work item 174 to change set.
User A deletes Folder1. When User A wants to deliver his change set to stream,he associate work item 175 to change set, he can see that there is incoming from User B.
To resolve conflict User A moves NTD.txt file to Folder2 as given in above link.
User A then delivers his change set to stream.

In this scenario when I fetch these change set programatically, I get two change sets having work item 174 and 175
for work item 175 everything is correct. 
For work item 174, it displays path of file as
Component/Folder2/NTD.txt, but this file was originally added by User B to Folder1.
If snapshots are compared in eclipse change explorer view I can see for work item 174 as
174  Folder1/NTD.txt.
When same change set is fetched using Java API,
I get path as
174 Folder2/NTD.txt
How do I get Original path of file i.e. Folder1/NTD.txt using java API.

I am using
compareBaselineSets(targethandle, sourcehandle, null, monitor); method to comapre snapshots
 determineAncestorsInHistory(versionhandles, monitor); to get path of file.

vikrant kamble commented Dec 29 '15, 8:26 a.m.

Is this an achievable target.?

As per my understanding.
IChangeHistorySyncReport report = workspaceManager.compareBaselineSets(targethandle, sourcehandle, null, monitor);
List<IChangeSetHandle> outgoingchangeSetsHandles = report.outgoingChangeSets();
List<IChangeSetHandle> incomingchangeSetsHandles = report.incomingChangeSets(); 

Either there will be incoming change sets or outgoing change sets.
I am looping through these lists to access change sets.

IVersionableHandle after = change.afterState();
"after" will contain only file that is added to folder.
When I print path of its root folders, It prints full path where it resides, not the path where it was created.

2 answers

permanent link
Geoffrey Clemm (30.1k33035) | answered Dec 29 '15, 1:19 p.m.
To get the information you are looking for, you need to understand the RTC namespace versioning model.  A file version does not have a pathname, but rather has an item ID (of the file), a parent folder item ID (the ID of the file's parent folder), and the name of file in that folder.  So when you move a file, it is just a single change, where the new version of the file has a different parent-folder-ID from the predecessor version.
To compute a pathname of a file, you have to have a configuration context (commonly, a workspace, but could be a stream, baseline, or snapshot).   In particular (and this often confuses folks), there is nothing in a change set that stores the pathname of a file in the workspace where that change set was created.  So to compute a pathname of a given version, the underlying code will logically get the name of that file version it its parent folder (this will become the last segment of the pathname), then look up the version of its parent folder selected by the configuration context, record the name of that folder version (this will become the preceding segment of the pathname), then look up the version of the folder's parent folder, etc., until it reaches the root of the component.
So there are a couple of reasons why you can see different pathnames for the same version:
The first is that the pathname of that version is being computed against different configuration contexts.
The second is that when you are computing the pathname of a version that is not the version of that item that is selected by the configuration context, then you can either compute the pathname of that version, or you can compute the pathname of the version of that file that is currently selected by the configuration context.

vikrant kamble commented Dec 30 '15, 12:37 a.m. | edited Dec 30 '15, 12:40 a.m.

 Hi Geoffrey,

I compared two snapshots and In the change Explorer view of eclipse, when I right click on that file and click on Show history I can see that there are two versions of file.
Version Id 1 when it was created and Version Id 2 when it was moved to new location.
But How can I fetch version 1 of that file from change set. 
I guess as stated in your second paragraph for second case that when I am computing pathname of version that is not the version of that item that is selected by the configuration context, it is happening here. Version two is selected and therefore it prints the new path of file (If I am not wrong).

Geoffrey Clemm commented Dec 31 '15, 2:44 p.m.

We'll need someone with API experience to get you the exact API calls to make, but the predecessor information (the "before state") is stored in the change set data structure.

permanent link
sam detweiler (12.5k6195201) | answered Dec 29 '15, 9:13 a.m.
right.. it is after... you would have to find the matching 'before'
technically there are two changes, one delete and one add.. not a single rename.

vikrant kamble commented Dec 29 '15, 11:40 p.m.

User B is adding new file into folder1, therefore I guess there will be no before state for that file.

Geoffrey Clemm commented Dec 30 '15, 12:45 a.m. | edited Dec 30 '15, 12:46 a.m.

There is a before state, but it is a special null state.

vikrant kamble commented Dec 30 '15, 1:07 a.m. | edited Dec 30 '15, 1:09 a.m.

I would not be able to use before state in this case because it will be null which could throw me exception.

And as stated in javadocs for
beforeState() - Returns the "before" state of the versionable item, or null if the change is the addition of a versionable item to the configuration.
I guess I can not use this method.

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.