It's all about the answers!

Ask a question

IFileItem and its parents


Nicolas Dangeville (30612025) | asked Jun 15 '09, 4:09 p.m.
JAZZ DEVELOPER
Hello,

I have a deliver follow-up action on the server. From the changeset, I
obtain a change, then afileItem. Now I'd like to obtain the project. I
noticed that there's a getParent () method but the handle it returns cannot
be used to obtain content ot navigate again, because its stateID is not set.

I recently found configurationDetermineAncestorsInHistory in SCMService that
does what I'm looking for. but I see there's an operation running and I'm
wondering if configurationDetermineAncestorsInHistory is expensive and if
there would be a more simple way to obtain the information.

Thanks,

Nicolas

One answer



permanent link
Heather Fraser-Dube (4512) | answered Jun 22 '09, 2:14 p.m.
JAZZ DEVELOPER
You could use IScmService.configurationLocateAncestors instead. It is not quite as expensive. The difference is though that you may receive null back. That would be the case where something was modified within the changeset being examined and deleted in another subsequent changeset also being delivered.

You also indicate you are looking for the project. Note that with the flexibility provided for sharing/loading content the top level folder is not necessarily the project folder.


Hello,

I have a deliver follow-up action on the server. From the changeset, I
obtain a change, then afileItem. Now I'd like to obtain the project. I
noticed that there's a getParent () method but the handle it returns cannot
be used to obtain content ot navigate again, because its stateID is not set.

I recently found configurationDetermineAncestorsInHistory in SCMService that
does what I'm looking for. but I see there's an operation running and I'm
wondering if configurationDetermineAncestorsInHistory is expensive and if
there would be a more simple way to obtain the information.

Thanks,

Nicolas

Comments
SEC Servizi commented Jan 26 '18, 11:29 a.m.
You could use IScmService.configurationLocateAncestors instead. It is not quite as expensive. The difference is though that you may receive null back. That would be the case where something was modified within the changeset being examined and deleted in another subsequent changeset also being delivered

Thank you heatherf for pointing that out: it helps us on a resolving path error.

Cheers.


SEC Servizi commented Jan 26 '18, 11:36 a.m. | edited Jan 26 '18, 11:39 a.m.

Funny thing: found there was a PMR for a very similar resolving path error we'd got.

Your answer


Register or to post your answer.