Community
Participate
Working Groups
When I activate a task and then apply a team patch I do not see the changed contents when I appy mylar settings. I need to physically open the files in an editor before mylar starts to track the content changes.
The problem is that Mylar considers all files not modified by you to be indirectly interesting, whereas files that you select and edit are directly interesting. Directly interesting elements show in filtered views like the Package Explorer, whereas indirectly interesting things are only used for operations such as change set management (so these files do get put into the active change set). On the Mylar project we work around this by asking that a context be attached with each patch that's submitted. But that's not realistic for all projects. So we should add support for this, although this will require some work because interaction monitoring is currently stateless (i.e. when resources change we don't know if it is as a result of a patch being applied or a refactoring completion). An easy alternative is to provie a "Mark interesting" action in the Synchronize view that would allow you to click a Change Set node or anything below it, and would have the effect of making everything contained within that node interesting (i.e. show up in the Pacakge Exploer). Thoughts?
By the way, can't we just parse patches attached to issue and reconstruct context based on the content of the patch?...
If you mean to get the Java element contents, yes, I think that's a better approach overall. but would be more work since the Apply Patch wizard is very closed (package private classes). Also, it would be a language-specific solution, an we would still want a generic solution. So maybe the right approach for now is to parse the patch for all changed files instead of relying on resource modifications. I'm not sure if we'll have a reasonable way to know when the Apply Patch wizard has finished, but could look into that.
(In reply to comment #3) > So maybe the right approach for now is to parse the patch for all changed files > instead of relying on resource modifications. That is what I meant. This should be quite portable because of the unified diff format. BTW, I've been trying to pull attached conttexts several times and found their quality quite bad. E.g. you can try to get context of that spellchecking issue that Rob completed... I believe got more context just looking at the patch.
By the context quality, do you mean that you'll see a bunch of folders without files in them? That's what I've noticed in a few cases, and will be resolved with bug 118542 and related context model improvements that are scheduled for 0.7/1.0.
(In reply to comment #5) > By the context quality, do you mean that you'll see a bunch of folders without > files in them? That's what I've noticed in a few cases, and will be resolved > with bug 118542 and related context model improvements that are scheduled for > 0.7/1.0. I guess not only that, but also context had none or just one relevant resource unfiltered in package explorer after I activated it.
Current work-around is to attach context with the patches. In the event that is not possible, the manual work-around is to select Open via the Synchronize view's context menu in order to manually populate the task context.
*** Bug 179600 has been marked as a duplicate of this bug. ***
Done. See comment on bug 179599.
Added documentation on this to the User Guide: http://wiki.eclipse.org/Mylyn_User_Guide#Working_with_patches
*** Bug 198898 has been marked as a duplicate of this bug. ***
