Community
Participate
Working Groups
From bug 119785: > However, if you have an active context and check a project > out of CVS each resource will be made interesting as it becomes a part of the > workspace (and as each becomes interesting the views will flicker). You mean *every* resource will become interesting? That seems very wrong to me. If I check out a project, the project itself should become interesting, but I have not yet worked on any files, so Mylar should not make any overriding decision about which files it thinks are interesting to me. I agree that explicit changes (file creation, or batch modification such as through patches) must mark the files as interesting, though. But I think Mylar should be about authorship, not what happens at the file level: When you do a CVS checkout, while it's certain creating files at the file-system level, it's not *authoring* files.
This is definitely the right idea. It will require some new infrastructure to implement because currently interest is only set by interaction events looked at individually, and sequences of events are not analyzed. But this won't be the only case requiring sequences to determine the 'intention' of the interaction, and it will make for a very interesting extension to the context model.
Eugene Kuleshov wrote the following, which sounds right to me. I'll post more when I've had a chance to try implementing it. > I think it would be more natural to verify if newly added or modified > resources actually reside within one of the projects that already have > other interesting resources for currently active task. > > This way you will also cover situation when user checkout new changes > for noninteresting project with automatic build enabled and Eclipse > run Ant builder registred for that project which could create new > resources (I saw this for Eclipse jdt projects)...
Eugne also added: > I am observing this issue when picking up new changes from the Sync > view that has global scope. So, changed resources added to the task > scope (not sure if all of them are added though). > > Actually it may be also necessary to add these updated resources > into non-active mylar tasks that include updated projects.
Moving post 0.5.0, which means it's still usuall a good idea to deactivate the context before checking out, etc, even though the behavior has improved for that case (less refresh, interest of new resources is only temporary).
Eugene's comment from mylar-dev: > -- picking up interest on externally changed resources (e.g. after vcs > checkout or build). This been discussed many times and we don't have > acceptable solution yet. If user not intentionally run background > checkout when task is active, he may literally loose his context because > of those incoming changes and the worst part that because context may > grow very big, whole IDE became unusable. > I think that it would be much better to do not include changed > resources (at least on checkout/refresh) unless they are within one of > the projects that already have interest. Though, in my understanding, > current problem is that Mylar does not know in context of what operation > resource has gain its interest...
*** Bug 157804 has been marked as a duplicate of this bug. ***
Fixed resource exclusion problem causing only first item on Preferences -> Mylar -> Resources to be used in exclusion.
Created attachment 53157 [details] mylar/context/zip
For 1.0 I have added the work-around (deactivate task) to the new Tips & Tricks document: http://wiki.eclipse.org/index.php/Mylar_Tips_and_Tricks Post 1.0 we will have do some of the revamping suggested above.
*** Bug 166938 has been marked as a duplicate of this bug. ***
We still don't have a good implementation strategy for this, but marking P2 since it goes against user expectations.
*** Bug 188288 has been marked as a duplicate of this bug. ***
The work-around is still the same (deactivate task) and the performance of both deactivation and a full checkout with a task active have been improved.
Need to investigate a better approach to this for 3.0.
*** Bug 202793 has been marked as a duplicate of this bug. ***
*** Bug 210403 has been marked as a duplicate of this bug. ***
Need to figure something out for Mylyn 3.0, especially for the cases of project opening and source control checkout.
*** Bug 227454 has been marked as a duplicate of this bug. ***
As an alternate strategy to trying to fix the root cause (that Mylyn is listening to events which are too broad), couldn't we put a listener on the open project event to turn off a Mylyn task whilst the open project task is executing then re-activate the task when the project has completed? I am an Eclipse event newbie though so I wouldn't know if you could listen on a project open/close event, but if you could... Then again, if this is going to be fixed, I guess an entire fix is better then a partial quirk filled fix - but considering this has been a known issue since 2005, doing something to improve the situation would be good.
David: that's a good suggestion. When I took a quick pass at doing that I could not find a good way to determine when the project has finished opening. For example, another project could be opened in the middle of the first opening, and then something else could kick off some synchronization. One approach that Shawn Minto and I have been exploring is to use the timestamp information from files to ensure that only ones that are created or modified while a task is active are added to the task context. This would address the case of opening a project, but probably would not address the case of project checkout from CVS/SVN.
*** Bug 182949 has been marked as a duplicate of this bug. ***
Created attachment 103860 [details] patch Here is a patch that uses the last modification date to determine whether resources should be added to the context. This works well for CVS checkouts except that folders dont have the old timestamp. For CVS update, there is still a problem since there is a good chance that the incomming files were modified at the same time that you were working. Also, opening closed projects will not affect your context unless the file was changed while the project was closed. The only thing that could be seen as a regression is that when a file is copied or moved to a directory on disk (not in eclipse), the files are never added to the context since the file modification time hasn't changed even though it is a new resource. If the file is created new, it will show in the context properly.
Created attachment 103861 [details] mylyn/context/zip
Argh, this is so close to the solution we want, but we can't go ahead as is given the problems you outline, because in too many cases files created by the user will not show up in the task context. Tomasz: do you know of any org.eclipse.core.resources experts who might know of a mechanism for determining modification timestamps of the form we're after?
If you are interested in CVS, you may be able to make use of the Subscriber API (available from the RepositoryProvider for the project) to determine if a file has been modified locally (i.e. has an outgoing change). That is, if a file is added, you could then ask the Subscriber whether the file has an outgoing change. If it does, it was probably added by the user. This API is available for any repository provider to implement. I think SVN uses it and there may be others. However, as with most Team API, if is not required tat a repository provider implement the API so it may be a good idea to isolate the use of Subscriber behind a Mylyn API that other repository providers could implement if they want to provide the same type of support (do I sound like a broken record ;-).
Michael: thanks for the tip! We will explore this, as it could handle the problem case with files becoming interesting when checked out of CVS and SVN. The underlying will still there though, because we need resources that are added to the workspace to become interesting. These come in two forms: 1) User creates a new file 2) User drags an existing file into the workspace The cases where we don't want to become interesting are: 3) A project is checked out of CVS 4) A project is opened The problem is that we haven't been able to formulate a test that satisfies all of the above. Using the last modification is almost it because it satisfies 1,3,4. But it fails to make files dragged into the workspace interesting because their last modified date is old. So we still have no test for whether a file is newly added to the workspace even if it was previously created on the local filesystem. We thought about using the "Accessed" file attribute, but that's probably Windows specific and hard to get from a resources. Do you think it's worth for us to pursue the Resource.getModificationStamp() integers? We took a brief look at those but got confused and it looked like they didn't contain enough info for this distinction. Regarding the Team API stuff, I'll comment on bug 116084.
Need to defer until we figure out a design for this. On the bright side, the performance and queuing of focused view refresh has improved to the point where checking out or opening a project no longer causes the problematic UI hangs.
*** Bug 256865 has been marked as a duplicate of this bug. ***
This is how we detect that team changes have occurred. I don't know if it'll work for Mylyn or if it'll work with every team provider. It works reliably for us with Subclipse: bc.. public class TeamResourceChangeListener implements IResourceChangeListener, IResourceDeltaVisitor { private boolean haveTeamPrivateChange = false; public void resourceChanged(IResourceChangeEvent event) { haveTeamPrivateChange = false; IResourceDelta delta = event.getDelta(); if (delta != null) { try { delta.accept(this,IContainer.INCLUDE_TEAM_PRIVATE_MEMBERS|IContainer.INCLUDE_HIDDEN); if (haveTeamPrivateChange) { // do something } else { // do something else } } catch (CoreException ce) { // handle } } } public boolean visit(IResourceDelta delta) throws CoreException { if (haveTeamPrivateChange) { return false; } IResource resource = delta.getResource(); if (resource != null) { if (resource.isTeamPrivateMember()) { haveTeamPrivateChange = true; } } return true; } }
*** Bug 259426 has been marked as a duplicate of this bug. ***
Created attachment 121264 [details] ignore resource deltas that incclude team private members
Created attachment 121265 [details] mylyn/context/zip
Thanks David! I did some testing with CVS and this strategy seems to work well. I have committed the attached patch. Please comment if there are any problems with missed resource change events when working bootstrapped.
(In reply to comment #33) > Thanks David! I did some testing with CVS and this strategy seems to work well. > I have committed the attached patch. Please comment if there are any problems > with missed resource change events when working bootstrapped. Glad that I could help. Great that it works for CVS too. Thanks for putting the time into this one. It'll make a big difference for my team, where we encourage people to update as often as possible. On a large project with over 20 developers there are always lots of changes. Having to deactivate the Mylyn task prior to updating was problematic for us.
Good stuff -- may I look forward to see this in this weekly build?
The fix is available in weekly builds >=I20081231.
Happy New Year! I wonder whether this also includes resources appearing by workspace refreshes. E.g. I add a file outside Eclipse, press F5 for refresh... and it is added to my context. In the same way, if an external tool is run and finally a workspace refresh is done, these resources would also be added. According to the bug description, this should be part of this bug. But it would be OK to rename it and move this to another one. Cheers, Jörg
Resource changes outside of the workspace that are picked up by a refresh are intentionally added to the context. That enables interest tracking for files edited outside of Eclipse. I would suggest to use bug 197942 to discuss further improvements to how workspaces refreshes are processed.
*** Bug 263026 has been marked as a duplicate of this bug. ***
*** Bug 308807 has been marked as a duplicate of this bug. ***
