It's all about the answers!

Ask a question

File in Pending Changes rendered in different colored font, why?


Ian Hodges (271013) | asked Jan 15 '15, 6:28 a.m.
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.

Pending Changes view showing two font colours

Thanks for your help.
Regards,
Ian Hodges.

Comments
Evan Hughes commented Jan 16 '15, 9:17 a.m.
JAZZ DEVELOPER

What API are you using to compute the final state of the file to verify?


Ian Hodges commented Jan 16 '15, 9:51 a.m.

Hi Evan,


I loop across the supplied change sets from deliverOpData.getChangeSetHandles(), these come oldest first (or at least they have in all the testing I have done).

I get the IChange/IVersionable's and check the file content.  If a later change set fixes the problem for a file then the "bad" file is removed from a failure Map used to populate an IAdvisorInfo.

Thanks
Ian..

Accepted answer


permanent link
David Lafreniere (4.4k7) | answered Jan 15 '15, 2:04 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
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.


Ian Hodges selected this answer as the correct answer

Comments
Ian Hodges commented Jan 16 '15, 4:08 a.m.

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..


Ian Hodges commented Jan 19 '15, 7:44 a.m.

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. 


David Lafreniere commented Jan 19 '15, 9:59 a.m. | edited Jun 29 '16, 10:45 p.m.
FORUM MODERATOR / JAZZ DEVELOPER

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.

Your answer


Register or to post your answer.