Community
Participate
Working Groups
When a task doesn't have context you must manually go through the CVS log to find related commit messages to determine what was changed to complete the task. It would be nice if Mylar provided some support for this. For example, Mylar could try to locate commit messages that contain the task id. Or Mylar could allow the user to select two different version of a file in the CVS history and select "Create Context from Changes," which would compare the two files and create context based on the changed structural elements.
Done via a new context menu action on context change sets that can be used to add one or more incoming or outgoing resources to the task context (e.g. via invoking on change set node or resource nodes). 3.3 dev build coming up soon, details will be in the New & Noteworhty.
Created attachment 62338 [details] mylar/context/zip
Mik, I'd say that you should have used separate IAdaptable for retrieving resources. Then non-cvs connectors could adapt their changesets to that adaptable and AddToTaskContextAction won't have to know about concrete implementations. Also, can you or Mark give me example of developer workflow when AddToTaskContextAction supposed to be used? I can't think why it can be useful for incoming changes and "compare with..." functionality in CVS provider is quite confusing. I.e. you can compare two tags/branches/time markers and ask Synchronize view to show changesets, but it won't show them quite right. Also, last time I tried that, menu contribution didn't work on comparison panel...
(In reply to comment #3) > Mik, I'd say that you should have used separate IAdaptable for retrieving > resources. Then non-cvs connectors could adapt their changesets to that > adaptable and AddToTaskContextAction won't have to know about concrete > implementations. This sounds good and could be worth doing. Please file a new bug if there is a driver. > Also, can you or Mark give me example of developer workflow when > AddToTaskContextAction supposed to be used? I can't think why it can be useful > for incoming changes and "compare with..." functionality in CVS provider is > quite confusing. I.e. you can compare two tags/branches/time markers and ask > Synchronize view to show changesets, but it won't show them quite right. Also, > last time I tried that, menu contribution didn't work on comparison panel... There following use cases have come up regularly: 1) Have incoming change set but no task or context for it, want to see what changed with it. 2) Apply a patch that had no context and want to review (for and Rob me this is more than once/week) 3) Make outgoing changes with no task active
(In reply to comment #4) > There following use cases have come up regularly: > 1) Have incoming change set but no task or context for it, want to see what > changed with it. Hmm. I think comparison in Synchronize view give more contextual data because you'll be able to see the changes. You'll loose that info after creating context from resources. Unless I am missing something. > 2) Apply a patch that had no context and want to review (for and Rob me this is > more than once/week) I got an impression that this feature only work in Synchronize view. Am I wrong? If not, how does it different from what sync view already provide? > 3) Make outgoing changes with no task active Can you please elaborate this one?
I'm not sure I understand your points. The main thing this feature lets you do is select a change set in the synchronize view that has a bunch of resources under it, and have all of those resources get added to the task context so that they populate the filtered Package Explorer. The only work-around to this was to open every resource so that the selection causes it to be added, which is fine if there are < 5, but not when there are more.
(In reply to comment #6) > I'm not sure I understand your points. The main thing this feature lets you do > is select a change set in the synchronize view that has a bunch of resources > under it, and have all of those resources get added to the task context so that > they populate the filtered Package Explorer. The only work-around to this was > to open every resource so that the selection causes it to be added, which is > fine if there are < 5, but not when there are more. I just don't understand how opening/filtering out package explorer is better then reviewing changes right from the Synchronize view + Comparison editor. I not really see a use case for creating resource-level context if changes already there. I guess the point I am trying to make is that this feature is not very intuitive (maybe just for me). I also don't think this particular feature would help Mark much. I could be wrong, but from my understanding he is more interested to retrieve and analyze deeper contexts for historical data (which is probably better to do using different tools, i.e. some king of "cvs log" analyzer/parser).
Marc: please comment if this is not what you wanted. This feature is definitely useful for me for reasons stated above. Of course I would still use the synchronize view for reviewing changes, but after a patch comes in with no context I often end up opening Java editors via the synchronize view, and that takes way too many clicks.
Mik, I see that "Add to Task context" action is contributed twice on Subclipse incoming changes...
On which kind of element, the change set or an IResource? I should be able ty try this in a bit.
(In reply to comment #10) > On which kind of element, the change set or an IResource? On change sets. Resources have just one menu.
Will try to investigate today...
Fixed by refining object contributions.
Created attachment 62583 [details] mylar/context/zip
