Understanding an IChange
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?
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
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:
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?
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
This discussion is 8 years old......
ok i have created new link for the same,
https://jazz.net/forum/questions/253798/understanding-afterstate-and-before-for-merge-scenarios