File in Pending Changes rendered in different colored font, why?
In a workspace I have a number of out going change sets which contain some merges. Most file names are rendered in a black font, but one is rendered in grey. What does the grey font signify?
This grey file, when processed by a Deliver IOperationAdvisor is, not being processed correctly as per the logic in the Advisor. I need to understand why it is different from a normal files to be able to update the IOperationAdvisor logic to cope with it. Unfortunately, I have only seen this problem on a production system so I cannot debug.
Thanks for your help.
Regards,
Ian Hodges.
Accepted answer
I suspect this is a 'no-op' merge, in which the before state and after state for that file is the same. If you try to open that in a compare editor, does it show that there are content differences? (I'm not sure off the top of my head how to easily reproduce a 'no-op' merge however).
Can you elaborate on what process advisor is failing and how? With the assumption that this file has equal before/after states, we can investigate the code for the advisor on our end to see if there may be a defect.
Can you elaborate on what process advisor is failing and how? With the assumption that this file has equal before/after states, we can investigate the code for the advisor on our end to see if there may be a defect.
Comments
Thanks David,
This was not a no-op merge there is a difference in the merged filed in the compare editor.
The process advisor is one which I have written to enforce copyright rules. If a file does not have a correct copyright the delivery op fails. In this case although the file had a correct copyright the advisor failed the delivery operation stating the file had an incorrect copyright year. The delivery op had two change sets that affected this file, the first which contained changes to the file, but with a bad copyright year and the second change set with the "grey" merged file which updated the copyright to the correct year.
Thanks and regards,
Ian..
This is indeed a no-op merge, but double clicking shows a difference between the change and a previous change set. The no-op change meant the before and after images were the same which defeated logic in my advisor. Thanks for your advise and help.
Also, for any future readers of this forum question, here are the steps to reproduce a NOOP change set.
1. Modify fileA.txt. Check-it into ChangeSet1 and complete the change set and suspend it. (Thus ChangeSet1 goes from States X --> Y)
2. Modify fileA.txt. Check-it into ChangeSet2 and complete it. (Thus ChangeSet2 goes from States X --> Z)
3. Resume ChangeSet1, this creates a conflict. It creates a new change set to resolve the conflict since both are completed. Now select "Resolve with Mine" and complete the change set. Since you are keeping your change, and discarding the one you resumed (or accepted in a more realistic work flow), and we are not adding anything new to the change set, the new merged change set goes from Z --> Z, which is a no-op and thus is grey.
Comments
Evan Hughes
JAZZ DEVELOPER Jan 16 '15, 9:17 a.m.What API are you using to compute the final state of the file to verify?
Ian Hodges
Jan 16 '15, 9:51 a.m.Hi Evan,