Community
Participate
Working Groups
Boris commented to me earlier that the custom splash handlers were not working (bug 173133). I stepped through the code to find out that all the calls to the splash API had been removed. Panicing, I found the change, and apparently I had removed it days ago as part of a submission that had nothing to do with the API. Now I'm pretty sure I didn't surgically remove the API accidentally which leads me to wonder how it was removed. I do a lot of crazy things but I really dont think this was one of them. :) I would've checked this bad change in from my windows partition running a different workspace. Is it possible that the update would've chosen the bad code in my workspace over the good code that I was updating to? No up to date checks failed when I had done this...
There's no much we can do without more information. If you can think of anything else that may have contributed to this, please include it.
I have identified one case where files could be unintentionally committed when using change sets (see bug 177031). I didn't reopen this bug because there is not enough here to link the two cases. Kim, if bug 177031 looks like it may have been what caused your problem, let me know.
Mmm yah. that could very well have been it. I logged into the window system to check in one very small change - I didn't synch before doing so. This workspace would've had the code that CVS was reverted to and all of these changes are in the same general area.
Reopening
*** This bug has been marked as a duplicate of bug 177031 ***
A similar problem has been seen again by Kim (although it involved changes not being committed instead of unwanted changes being committed). The steps were something like: 1) Apply a patch to multiple files. 2) Commit the changes from the Unassigned set in Change set mode (Kim, are you sure they were in the view at this point?) 3) After the commit, notice that a few files are still dirty but do not appear in the sync view 4) Changing to the workspace model and back to the Change Set model fixed the problem It appears to be related to the Unassigned category in Change Set mode. Either changes are not getting added or they somehow got removed by the commit without actually being committed. I believe the former is more likely.
I have not yet been able to track this down but I'll keep looking.
Incidentally, this hit us again - part of the fix for 170950 was not committed many moons ago.
Tomasz, can you try and reproduce this failure and try to figure out what the problem is. The problem mostlikely lies in the ChangeSetContentProvider.
I'm still trying -- no luck yet...
Kim, Michael, Boris, Szymon if you see it happen again please let me know. Attaching a patch or at least a screen shot of your Synchronize view would be a helpful thing without any doubt.
I have been able to reproduce this. Here is the scenario: 1) Have some outgoing changes and some incoming changes 2) One of the files must have a conflicting changes that are auto-mergable. - The file with the conflicting change MUST NOT be assigned to an outgoing change set. - When you expand the Unassigned category the conflict will not be there. It will only be in the incoming change set. 3) Perform an Update All. 4) The incoming change set containing the conflicting change is removed but the change is not re-added to the Unassigned set. The options to fix this are to either force a refresh of the Unassigned set whenever a set is removed (I will attach a patch for this) or to always ensure that Conflicting changes appear either in the Unassigned set or an Outgoing Change set (i.e. they would always appear twice. The second option may be better from a user standpoint so I'll investigate what the patch looks like for that as well.
Created attachment 68967 [details] Patch for option 1
Created attachment 68968 [details] Patch for option 1
I have logged bug 189663 to look at option 2 at a later time as it is not trivial. Kim, can I get you to review the attached patch?
I'm not familiar with the space but this looks entirely reasonable.
Fixed
Changing OS from Mac OS to Mac OS X as per bug 185991
