Community
Participate
Working Groups
When starting new developement there is a good chance that there will be commit to version control just before completion of the task. So, why not to use task description as a commit description text (and probably also allow to optionally close task from the commit dialog).
I think that this is a great idea because I'm always pasting the bug id and description into my commit message. How about we add a "Resolve and commit" button to the Task List? Then a dialog pops up with the ID for (or link to?) the bug, the subject, and space for you to add additional comments. E.g. Resolved: Allow to use opened task descriptions as comments in CVS commit https://bugs.eclipse.org/bugs/show_bug.cgi?id=106862 Last comment: bla bla bla
That is interesting. Actually I was thinking about automatically adding an active task name into comments text area in CVS commit dialog. But now that you've mentioned it there are some interesting possibilities: -- put an active task name into the commit comment. E.g: Task: 106862: Allow to use opened task descriptions as comments in CVS commit Note that there is no need to add an url, because it suppose to be configured per project. See issue 58646 or additional details. https://bugs.eclipse.org/bugs/show_bug.cgi?id=58646 -- as you've said use bug details to populate cvs commit comment -- use commit message to atomatically update attached bug report (e.g. post commit comment and the list of affected classes). This is usually done by some hooks on cvs/svn server, but IDE integration could be somehow interesting too.
Somme additional comments of Eugene's from bug#107085 that are relevant: > But could you clarify what you mean about monitoring CVS activities? Well, when you run syncronize and see bunch of incoming changes with comment like "107085, 107086" you sort of curious what the hack these bugs was about. Now I have to manually add them into the mylar task list in order to see description. It would be faster to be able to just type issue id. Another "fancy" way of doing this could be to drag resource (or folder/commit set on "commit sets" mode) from Synchronize view into the Mylar task list view and Mylar would try to find matching issues and add them as tasks. But I believe it would require too much heuristic.
This will be a nice feature to incorporate, but moving to next week. We have to be careful to ensure that it doesn't couple mylar too closely to org.eclipse.team.ccvs to ensure that the interaction is as convenient when other repositories are used.
Mik, shouldn't it be something like a "comment provider" extension point, so CVS plugin could use it to fetch comments from a current task?
That could be a good way of doing it--that way additional repository providers could create an optional dependancy to that Mylar extension point, and it would be easier to move the extension point into the team plug-in eventually. I'll probably do it as API first, and then propose the extension point on this report to get your feedback.
(In reply to comment #6) > That could be a good way of doing it--that way additional repository providers > could create an optional dependancy to that Mylar extension point, and it would > be easier to move the extension point into the team plug-in eventually. I'll > probably do it as API first, and then propose the extension point on this report > to get your feedback. It seems that team plugin should actually own such extension point, so other sources could contribute data to be used as commit comments (e.g. refactoring log or local history). We should invite Michael Valenta or somebody else from team component team to commit on this because this extension point could be another candidate for high level team integration API.
I just had almost the same idea for an enhancement request (although I've moved to SVN for lack of skill of setting up CVS on linux). It would be also interesting to be able to share task context in CVS, but the file sizes are probably too big for that. But somehow the idea of sharing task context between developers seems really cool to me -- maybe it could be done with ECF (Eclipse Communication Framework)?
(In reply to comment #8) > It would be also interesting to be able to share task context in CVS, but the > file sizes are probably too big for that. But somehow the idea of sharing task > context between developers seems really cool to me -- maybe it could be done > with ECF (Eclipse Communication Framework)? I think somebody already working on the prototype for this. Mik and Brock should be able to tell...
Erkki, we will make sure that the automatic generation of the comment will be easy to have work for SVN as well. As Eugene has pointed out this would benefit from some common Team functionality in the Eclispe SDK, but for now the best we can do is make a generic API and then suggest that Team integrate that at some point. Regarding your other suggestion: I couldn't agree more and support for automatically attaching contexts to bug reports will get done within a week or two (bug 113848). The contexts themselves are smaller than screen captures so size isn't much of an issue. On the Mylar project I'm considering requesting that all resolved issues get an attached context. That makes it way easier to review what was done when a patch gets submitted, etc. In case any design issues come up, could you add yourself as a CC to that report?
Done: there is now a new context menu called Commit Resources in Context... that will commit everything in the task context and fill the description of the task into the comment area. Details will be in the New & Noteworthy. Note: this is an Eclipse SDK-specific (i.e. CVS) feature. However, I used the ChangeSet mechanism, so any other plug-in (e.g. Subclipse) should be able to use this functionality. What such a plug-ins commit wizard would need to do is the same as org.eclipse.team.cvs.ui's CommitWizardCommitPage.getProposedComment(..) does and get all the active ChangeSets, and see if one of them (i.e. the MylarDynamicChangeSet) has a proposed comment for the resources that are to be committed.
Cool stuff! I coudn't wait and tried this feature using code from CVS. I think that it would be more intuitive to the user to have commit action on the Mylar's dynamic change set node in Synchronize view. Also, to keep you busy there are issues 115705, 115707 and 115709 :) Also note that Subclipse plugin have no support for change sets and it is unclear if/when it will be added there.
No, Subclipse does not yet support change sets yet. There are no technical reasons why it couldn't be added though. In Subversion each revision is in effect a changeset. The biggest problem is that the ChangeSet API is internal at the moment.
(In reply to comment #13) > No, Subclipse does not yet support change sets yet. There are no technical > reasons why it couldn't be added though. In Subversion each revision is in > effect a changeset. They are saying that they not very interested in this and don't even use sync view tehmselves. So, I got an ipression that it will stay like this until something happens or they won't have anything else todo. > The biggest problem is that the ChangeSet API is internal at the moment. Brock, can you please open an issue to team plugin for this?
(In reply to comment #14) > (In reply to comment #13) > > No, Subclipse does not yet support change sets yet. There are no technical > > reasons why it couldn't be added though. In Subversion each revision is in > > effect a changeset. > > They are saying that they not very interested in this and don't even use sync > view tehmselves. So, I got an ipression that it will stay like this until > something happens or they won't have anything else todo. If there was a patch, Mark wouldn't reject it. The only problem is that he will not accept anything that introduces a dependency on 3.1 API as Mark is developing mostly on RAD. Last night I implemented a change set provider for subclipse that supports outgoing changesets (the bit required for Mylar). I will check it into a branch so it doesn't get lost. It might also encourage people to look at adding the checked in changesets. > > > The biggest problem is that the ChangeSet API is internal at the moment. > > Brock, can you please open an issue to team plugin for this? Done, bug 116084. I doubt it will get done for 3.2 though.
(In reply to comment #15) > If there was a patch, Mark wouldn't reject it. The only problem is that he will > not accept anything that introduces a dependency on 3.1 API as Mark is > developing mostly on RAD. Last night I implemented a change set provider for > subclipse that supports outgoing changesets (the bit required for Mylar). I > will check it into a branch so it doesn't get lost. It might also encourage > people to look at adding the checked in changesets. I wonder if this feature can be distributed as a patch to Subclipse or maybe as an optional feature with dependency on Eclipse 3.1
It's disappointing that bug 116084 indicates that Change Set support isn't likely to be made APIs for 3.2. So I wonder if Eugene's suggestion of having an seperate or optional Subclipse plug-in that has the 3.1 internal API dependancy. Note that you could consider making this an optional dependancy, and try to fail gracefully if it isn't satisfied. Require-Bundle: org.eclipse.ui, org.eclipse.team.ui;bundle-version="[3.1.0,4.0.0)";resolution:=optional,
