Community
Participate
Working Groups
I didnt see anything like this in the current enhancements so forgive me if this duplicates something. Before explaining the request, Ill explain the scenario. Lets say I have 3 branches of code: PROD, TEST, DEV. Each one is its own project in eclipse. I have 3 working sets defined, one for each. I can easily switch bewteen them in the Task List. Lets say I had a task named: FixTheBug. Its context was some resources in DEV. I dealt with it last month. I am working today with my working set on TEST. I now activate FixTheBug and my edits are now open to resources on DEV (which is not even part of my working set filters). Not thinking, I start editing some resources until I realize I am on the "wrong" working set. So here is the request which I admit is not totally thought through. When activiating a context, the system validates that all resources are ones that would pass the filter as set in the TaskList workingset. If this validation fails, it does at least (1) and ideally (1,2): 1) warning dialog that some resources are not in your current working set. 2) Prompt you to duplicate the context and somehow migrate the resources to those in the active working set (to the extent possible). This intutively makes sense when different working sets represent substantially simmilar branches of code. There is something that transends mylyn that perhaps the platform core might do better. When working on substantially similar branches = projects in eclipse, one sometimes has an edit open on file X asks "how does file X compare to the same file in another project". Of course you can manually diff them or compare with another svn or cvs branch, etc. But it might be nice if eclipse or some plugin has some better understanding of cases like this to make navigation a bit faster.
Alan: I wonder if us figuring out the right policy for bug 195457 would meet your needs?
Im not sure I understand the current status of bug 195457 so correct me if I am wrong. It seems like you are saying 2.1m1 will now not switch working sets when a task is activated. And you are asking what the policy should be regarding changing working sets when activating tasks. I guess this issue could be viewed as one suggested policy, although I would guess my request (item 2) is a rather complex implementation of a policy. Also, I think the author of bug 195457 has a use case wherein he just wanted his task to ultimately get him back to his branch (granted however he wants the ShowAll still selected). My usecase is different in that I want to somehow migrate my task to a different working set representing a different but substantially similar branch of code. Thanks for entertaining this request. I realize it might be a bit obtuse :)
I think that we need to stick with our current solution, since it avoids popping up dialogs and is pretty flexible: * The focus filter on the Package Explorer removes the working set filter, ensuring that if elements from different workign sets are selected, they show * The Task List allows containers to come from different working sets If there's a suggestion for a better policy we could consider it.
