It's all about the answers!

Ask a question

Identifying before and after path for IChange in ChangeHistory


Steve Ashton (824) | asked Jul 18 '14, 9:47 a.m.
edited Jul 18 '14, 10:28 a.m.
 I am trying to distinguish between add/update/delete/move actions taken on files when looking at a change history.  I was assuming that I would be able to use the beforeState and afterState of the IChange to decide what action was taken. For example, I would have expected the before/after state for a delete to be [content/null] respectively, instead the after state still contains the content of the file.

I must be thinking about this the wrong way. Is there a better way to correctly identify what happened to a file?  Related, how would I determine the before path and the after path for a file move?
I am currently using  configuration.determineAncestorsInHistory(fileHandles, MONITOR); to get the path of an IChange, but I assume that only gets me the after path. How would I get the before path?

EDIT:  Updated title to reflect changes to question. I realized I was missing seeing the after state for the IChanges which were deletes.  So now my question really relates to the second paragraph... How do I get the before path and the after path for a given change? I am getting the same path for both changes when i moved a file by deleting it and then adding it to another folder.

This is how I am getting the paths right now:

List<IVersionableHandle> fileHandles = new ArrayList<IVersionableHandle>();
for (Object changeSetO : cs.changes()) {
  IChange changeSet = (IChange) changeSetO;
  IItemHandle itemHandle = changeSet.item();
  fileHandles.add((IVersionableHandle) itemHandle);
}
IConfiguration configuration = wc.configuration(cs.getComponent());
List<IAncestorReport> list = configuration.determineAncestorsInHistory(fileHandles, MONITOR);

Accepted answer


permanent link
sam detweiler (12.4k6173200) | answered Jul 18 '14, 10:19 a.m.
according to the java doc (you are looking at the javadoc, right?) null state before means add, null state after means delete

then you would look at the merge type I think if both before and after are not null.

but one fo the SCM team folks should be along shortly to add/correct

Modifier and Type Method and Description
IVersionableHandle afterState()
Returns the "after" state of the versionable item, or null if the change is the deletion of a versionable item from the configuration.
IVersionableHandle beforeState()
Returns the "before" state of the versionable item, or null if the change is the addition of a versionable item to the configuration.
int getMergeKind(IVersionableHandle mergeState)
Returns the change kind which describes the type of change between the supplied merge state and the after state.

Steve Ashton selected this answer as the correct answer

Comments
Steve Ashton commented Jul 18 '14, 10:32 a.m.

 Thanks for the info. I've edited my question to match. My remaining question is about file moves and how to get the path from before the move as well as the path after the move.


sam detweiler commented Jul 18 '14, 10:46 a.m. | edited Jul 18 '14, 11:23 a.m.

sorry, I do not know the answer to that.

but looking at IConfiguration again

java.util.List locateAncestors(java.util.List versionableHandles,
                             org.eclipse.core.runtime.IProgressMonitor monitor)
                               throws TeamRepositoryException
For each specified item, retrieves the sequence of name-item pairs that leads to that item in the configuration starting at a root folder. It is assumed that the reference versions can be found in the component that scopes this configuration.

This information could be turned into a path by combining the names from each folder entry in sequence. The operation fails by throwing TeamRepositoryException if the client is not logged in to the repository.

There can be at most one path to any particular versionable item in a configuration. A folder namespace is a strict tree with a single root for each component; there is no equivalent of Unix-style hard links.

so it sounds like you can get the data to construct the current path.



Steve Ashton commented Jul 18 '14, 11:24 a.m.

sam detweiler commented Jul 18 '14, 11:30 a.m.

thanks for the feedback.

Your answer


Register or to post your answer.