Community
Participate
Working Groups
I noticed this due to problems with Mylar's automatic change sets, but the problem is identical for user-created sets. Sorry I didn't report this sooner, thought I was using model-based synch since the pref was on, but had an old synchronization sticking around. Steps to reproduce (3.2RC4): 1) put view in Change Sets mode (3rd toolbar button/pulldown) 2) create an outgoing change (i.e. modify a file connected to CVS) 3) file will appear, add it a new change set (creating the set) 4) restart Eclipse, click "Populate" in Synchronize view 5) Message will be "There are no more Outgoing changes for Change Sets. However Java Workspaces has changes in Outgoing mode" 6) Toggle mode to "Java Workspace", then back to "Change Sets", change will appear, should have appeared for (5) Related problem: when an automatic Mylar set is first created it gets no icon or label (oddly it gets its decoration). Doing step (6) above causes the icon and label to appear. To add the set I'm calling ActiveChangeSetManager.add(..) which works fine with the old page. Is this part of the above bug or should I be calling something to kick off a refresh? Gripe: I don't like the need to click "Populate" on startup, since to me it feels like Eclipse hasn't restored itself after shutdown. Is this necessary? Question: the "Commit..." and related actions are now disabled for Mylar's subtype of ActiveChangeSet (weren't on old page) and can only be performed on the node's children. What is the check being made to disable these, I need ensure they are enabled.
I've seen this during view population as well. However, it doesn't happen all the time for me. Re: Missing labels: Not sure what could cause this. Do you have a label provider for your change sets or are you using the label and image provided by Team? Re: Gripe: See bug 140088 for a request to do auto-population. Re: Commit: You need to adapt your change set to a ResourceMapping. CVS adapts the CVSActiveChangeSet to a ResourceMapping but there is no general mapping for ActiveChangeSet.
Thanks Michael, adapting to ResourceMapping did the trick for getting the actions back. Missing labels: I do not have a special label provider and simply rely on the standard one provided by Team. The bug is that I get no icon and lable (just a clickable blank tree node), when the set is first added. If I toggle the models the labels show up properly from that point forward. It's as if I should be doing more than ActiveChangeSetManager.add(..) to get my set properly registered, since this bug doesn't occur when a new set is created manually. Is there anything else I could try calling to properly update or force an update/refresh? Regarding this bug: I'm surprised it's been set for 3.3, since I get this every single time, and in other words manual/user sets (and hence Mylar sets) are broken. If it's really off the table for 3.2 I guess the only thing we can do to work-around it is to to somehow programatically cause the refresh that's done by the models switch?
I am not able to reproduce this reliably so have not been able to scope out a fix. It is definitely to late for 3.2 but a fix for 3.2.1 could be considered if the fix was not too complicated. If you can provide a 100% reproducable set of steps or can track down the problem and provide patch, then we could consider fixing it for 3.2.1.
For me the steps in the description fail reliably both in a test workspace and in a runtime workspace. Simply using the manual change sets and a single project checked out of CVS. I didn't bother clearing the workspace data, should I try that, or is there some other difference in what you're doing that might result in the failure to reproduce?
Is this being looked into or do you need more information?
We are not investigating this issue at the moment. We would like to look into it in 3.3 but it really depends on what prioirities come out of the 3.3 planning.
Please consider giving this priority: in it's default configuration (Allow models..) the Synchronize view is broken when using change sets. I just tried steps 1-6 in the description with a plain RC7, no Mylar or other plug-ins, no metadata or settings other than a single project checked out of CVS. The change set fails to appear every time on restart. It only appears again if the Models are toggled back and forth. I'm marking this as "major" because to a user unaware of this refresh bug it appears that they have lost workspace settings that they created (any change sets), and the way to get them back is not obvious. And for those that it is obvious to it makes this funcionality appear flaky. With a clean Eclipse you should be able to reproduce this by following those steps. Just fyi, for the past couple of months or so I have been using Mylar's change set management in the model-based mode in spite of this bug because I really like seeing Incoming and Ougoing sets at the same time. This is the only bug I have noticed.
It seems there is one more related bug: bug#152988. There is a screenshot attached. If there is something I could do to help reproduce this, let me know.
As far as I can tell the steps I provided in the description still cause the failure. Note that they don't require Mylar to be installed and can be triggered with manually-created change sets. Startup is not the only time this bug manifests itself. For example, every once in a while it takes two modifications of a resource in order for it to appear in a change set that the resource is a part of. Also, in my experience that the 3.3 option to automatically synch on startup often works around this bug on startup, probably due to the extra update/refresh it triggers. Willian: I once saw a label decoration problem like the one you're pointing to, but it hasn't happened to me for a long time.
(In reply to comment #9) > Willian: I once saw a label decoration problem like the one you're pointing to, > but it hasn't happened to me for a long time. > Yes, I haven't noticed it anymore too. Not sure if something changed or I'm lucky...
Unfortunately, we do not have the cycles in 3.3 to address this issue. I have created an FAQ entry describing the model-based vs. old-style synchronizations: http://wiki.eclipse.org/index.php/CVS_FAQ#Synchronizing_has_some_regressions_in_Eclipse_3.2._Why.3F
I found and fixed a race condition that may have fixed this so I'm marking it fixed in M6. However, if you still see the problem with an M6 or later build, please reopen.
Great, thanks. Will watch for it and post if I see it occur.
(In reply to comment #12) > I found and fixed a race condition that may have fixed this so I'm marking it > fixed in M6. However, if you still see the problem with an M6 or later build, > please reopen. I think that I'm noticing an improvement, because I haven't had to toggle modes manually, and instead now see the changes drop into the "<Unassigned>" eagerly. Note that this is just from observation and not from thorough testing. However, I still think that there may be an underlying bug here because I sometimes see "Null label" instead of "<Unassigned>", and toggling modes fixes that.
Thanks. The "Null Label" problem was fixed early in M7. The work around is to click on Incoming mode and then on Outgoing (or Both).
*** Bug 142280 has been marked as a duplicate of this bug. ***
Michael: I've been noticing much more frequent change set refresh/update problems with the Synchronize view with RC3 than with previous builds. I frequently have to toggle incoming/outgoing to see a new change set that has been added. I haven't had a chance to investigate and plan on doing so this week, but nothing changed on the Mylyn end so I'm wondering if there was any refresh functionality was changed on the Platform/Team side?
I don't recall any changes that would have affected that. There were some changes but they would not affect change set addition (i.e. on change set removal, we needed to refresh the Unassigned set to ensure changes were not lost). How are the change sets being added (i.e. are they Mylyn change sets)? Also, could you check the log.? There were some checks added to the TreeViewer to avoid reentrant calls to the tree. It is possible that that is having an effect.
Fyi, still noticing the same thing with RC4. Sometimes I also get a blank change set node and have to toggle to have it's label and icon appear (i.e., it was added, bug something not refreshed). Yes, they are Mylyn change sets. Nothing in the log, this appears to be purely a refresh problem. I realize that I did make one change that could be responsible. Previously our change set, ContextChangeSet, was a subtype of CVSActiveChangeSet. It is now a subtype of ActiveChangeSet. That seemed OK because CVSActiveChangeSet has no implementation, but we could be falling through some switching or dispatch on the type. I will revert and report back later today.
It does appear that using ActiveChangeSet instead of CVSActiveChangeSet causes this refresh problem, because switching back fixed it. While using CVSActiveChangeSet unnecessarily couples mylyn.team.ui to CVS, it's OK for us to leave this coupling in place for Europa and address it after. Should I submit a new bug? Even though these are internals (bug 116084), it seems like the refresh policy should be generic, not CVSActiveChangeSet specific?
The issue is that the CVS change set support wasn't really designed to accommodate third party change sets. If you're going to log a bug to request that the CVS change set support work for subclasses of ActiveChangeSet, it would be good to include a patch for it as well (since this would be the best way to ensure that the code works for your use case).
Michael: I'm still seeing refresh problems with the synchronize view when change sets are used, even if Mylyn is not present. Toggling the incoming/outgoing mode always fixes the problem. Should I reopen (note that this is no longer related to restart), file a new bug, or is there a Platform/Team bug we can investigated this on? I can do some digging through the code myself, especially since I'd like to get refresh working properly for ActiveChagneSet and not just CVSActiveChangeSet.
I don't recall any currently open issues involving change set refresh so you could probably just open a new bug.
