It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,877
×10,913

question asked: Aug 23 '10, 5:59 p.m.
question was seen: 6,104 times
last updated: Jun 14 '18, 7:10 a.m.

Related questions

Understanding an IChange

0
Danil Suits (81●17●7) | asked Aug 23 '10, 5:59 p.m.
We did a merge today, and got crossed up when our java code tried to pull down the change set. I think the problem is that our assumptions are bad, so I'd like to check here.

The use case is that, since last week's merge, file A was updated in Source, and deleted from Target. We went through the following sequence.

1) Updated our workspace repository by accepting all of the incoming change sets from Target.

2) Updated our workspace repository by accepting all of the incoming change sets from Source. This introduces merge conflicts, including file A (where it was updated).

3) Resolve the conflicts locally, preserving the change that A was deleted in target.

4) Deliver the merged files to Target.


My java code is watching the changes in this history of the target component. What should we expect the IChange that represents file A to look like when we fetchCompleteItem on the relevant IChangeSetHandle?

3 answers

Most liked answers ↑|Newest answers|Oldest answers

1
permanent link
Danil Suits (81●17●7) | answered Sep 13 '10, 12:17 p.m.
I suppose the bit that really surpises is that IChange.kind() returns IChange.NONE in this circumstance.
0
permanent link
Geoffrey Clemm (30.1k●3●30●35) | answered Aug 23 '10, 10:55 p.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER
As I recall, a change consists of two states ... a from-state and a
to-state, and in a "delete" change, the to-state is null (and in a
"create" change, the from-state is null).

If my memory is faulty, I assume someone from the SCM dev team will
clarify/correct.

Cheers,
Geoff

On 8/23/2010 6:07 PM, Danil wrote:
We did a merge today, and got crossed up when our java code tried to
pull down the change set. I think the problem is that our
assumptions are bad, so I'd like to check here.

The use case is that, since last week's merge, file A was updated in
Source, and deleted from Target. We went through the following
sequence.

1) Updated our workspace repository by accepting all of the incoming
change sets from Target.

2) Updated our workspace repository by accepting all of the incoming
change sets from Source. This introduces merge conflicts, including
file A (where it was updated).

3) Resolve the conflicts locally, preserving the change that A was
deleted in target.

4) Deliver the merged files to Target.


My java code is watching the changes in this history of the target
component. What should we expect the IChange that represents file A
to look like when we fetchCompleteItem on the relevant
IChangeSetHandle?
0
permanent link
vinitha dsouza (147●2●23●136) | answered Jun 13 '18, 1:49 p.m.

Same case happens to me. What exactly should happen here if it is file?
What should happen if Folder is went to above steps.
i am using FetchCompleteItem (VersionHandle) which is null in this case if after and before.
Not sure how to get the File Name in this cases.

Comments
Ralph Schoon commented Jun 14 '18, 2:39 a.m.
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER

This discussion is 8 years old......

vinitha dsouza commented Jun 14 '18, 7:10 a.m.

ok i have created new link for the same,
https://jazz.net/forum/questions/253798/understanding-afterstate-and-before-for-merge-scenarios

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.