It's all about the answers!

Ask a question

An follow-up after resolving evil-twin


Wai Hung Lau (21165) | asked Sep 25 '12, 2:53 a.m.
 Our scenario is like this:
Feature Stream  
- change set a: add file a.txt
- change set b: modify a.txt

Mainline Stream
- change set c: add file a.txt

private workspace <-> Mainline Stream
- out going : c
- incoming : a, b


First, in our workspace we accepted change set a. Then resolve this "evil-twin" as mine. I understand for file a.txt, it will only keep the history of c. 
Later, we accept change set b. Then conflict was shown as deleted<->modified. 

Problem :
We want to merge the change of b back to mainline. But when we use merged with proposed, it will ask me to move the conflicted file. I think the solution should delete the local a.txt which reference by change set c to resolve the move conflict but no success. Is there any solution?

One answer



permanent link
Chris McGee (50511117) | answered Oct 03 '12, 12:07 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
In this scenario it seems that the Mainline Stream twin of a.txt is the most important and its history should be easier to get at in the future than the other twin from Feature Stream.

You could try the following steps to resolve the conflict and avoid constant conflicts as changes are made to a.txt from the Mainline Stream:

1) Copy all of the latest contents of a.txt from Feature Stream to the clipboard

2) In Private Workspace, discard A and B plus any "Merge" change sets you have involving a.txt
You can do this from the pending changes view. Right-click on the component with a.txt in it and choose "Show History." It will provide a list of all change sets accepted into the component in your repository workspace. Multi-select the change sets, right-click and choose "Discard..."

3) Accept change sets A and B again

4) Resolve the conflict with "Mine"

5) Paste back in the contents of a.txt copied from step 1

6) Check-in the change of contents into the "Merge" change set created in step 4

7) Deliver change sets A, B and Merge into Feature Stream

The users working on Feature Stream will now be working with the a.txt twin from the Mainline stream. The history of the twin of a.txt in the Feature Stream is still preserved and can be discovered through the Merge change set because it contains a change to both a.txt twins. When Feature Stream eventually delivers everything to Mainline Stream all of the change sets and history of both twins will flow over.

Comments
Chris McGee commented Oct 03 '12, 1:20 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

Version 4.0 of RTC should be able to handle the evil twin resolution case in a better way than described above.

1) Accept change set A
2) Resolve with Mine
3) Accept change set B
4) Merge changes to a.txt
5) Check-in local changes to a.txt into new Merge change set
6) Deliver A, B and Merge change sets to Feature Stream

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.