Community
Participate
Working Groups
The support that synchronizing Mylar change sets provides is excellent, as far as annotating commit logs with the task ID. However, it'd be nice to close the loop on this and have synchronizing the Mylar change set also move the bug to "fixed" and annotate the report with a template that could include the source repository revision number(s). Even if this isn't the default behavior (to allow multiple commits for the same task), it'd be really nice if it was an option when completing a task. Right now, we have to append manually the SVN revision number to the Bugzilla bug report for posterity.
I think it would be easier and generally a better option to add a on-commit hook to svn that would post something into the Bugzilla. Doing it from Eclipse is more difficult, at least because there is no common API for committing stuff and not all VCS providers have concept of the revision number.
It's surprising that there is no common API for committing stuff, consider how nicely the automatic change sets commit with the Subclipse Mylar connector. This whole Mylar scheme and implementation is really fantastic. The hook script approach loses a lot of fidelity and relies upon parsing particular spew in the commit log; variations in that spew, including additions, could result in messes that would have to be cleaned up manually. Mylar, however, has a much better knowledge of what is happening, given its task orientation, and wouldn't have to rely upon error-prone parsing; you could close out a task, and this process would know which task to annotate (just as it's clear which task to describe in the commit log). Another major drawback to accomplishing the effect I want through hook scripts is that hook scripts affect an entire repository. Having made effective use of hook scripts in the past, I know it can be tough to avoid minor errors that block other users, especially if the structure of the repository changes. Also, it's more difficult to implement per-team policies via the hook script approach. You either have to set up a separate repository per project/team, or you have to install these hook scripts and trust that you haven't messed anything up for other projects/teams using the same repository (and all the negotiations that entails). Both seem like sort of a backwards way of accomplishing this effect compared to Mylar. Is there no way to have templates that are aware of repository number(s)? Or instead, would it be possible to extend the Mylar connector API such that a given Mylar VCS connector could publish arbitrary per-transaction values, and the keys to those values could be used in the templates? It seems like Mylar could know this information, if a common representation could be agreed upon. At any rate, keep up the good work!
(In reply to comment #2) > It's surprising that there is no common API for committing stuff, consider how > nicely the automatic change sets commit with the Subclipse Mylar connector. Well, this is how it is. All Mylar does is providing that comment text and the rest of the dialog is actually owned by Subclipse, which is not even part of Eclipse distribution. > This whole Mylar scheme and implementation is really fantastic. > The hook script approach loses a lot of fidelity and relies upon parsing > particular spew in the commit log; variations in that spew, including additions, > could result in messes that would have to be cleaned up manually. You are forgetting that comments would come from Mylar so their format will be known, or else you can skip processing if you can't parse the comment. > Is there no way to have templates that are aware of repository number(s)? In theory it is possible. But in practice it will require more tight integration with specific VCS provider (i.e. Subclipse) and be able to get back the revision number after commit. Note that there could be multiple revisions produced by one commit action from Subclipse (i.e. in case when Subclipse is using JavaHL and committing resources from several projects). > instead, would it be possible to extend the Mylar connector API such that a > given Mylar VCS connector could publish arbitrary per-transaction values, and > the keys to those values could be used in the templates? It is still unclear where this stuff would be stored and how it would be communicated between Mylar and VCS providers. BTW, why do you need revision id in the bug report? You can just open history view for the project and just search by the bug id. Or even narrow it down by opening context for that report and then looking trough history for the resources from that context.
I'm not disputing that the hook script approach could be done (and I know that there are solutions out there along these lines); what I am saying is the hook script approach is inherently lower fidelity and potentially quite fragile. The reason we started doing the (currently manual) process of including revision numbers in bug reports when they are marked fixed is that searching the history is similarly clumsy and error-prone. We use this backreference to the revision number(s) very often during formal code reviews, such as during change control committee meetings that occur close to product releases. In such circumstance, we weigh very carefully whether any of the code changes will be allowed to be submitted for the build, and it's problematic to miss reviewing any of them. Searching the history is less fragile for Subversion projects, if they're all hosted in the same repository, since a single revision number covers all of the committed changes. However, CVS users would have a tougher problem, in that they'd have to search the history of every single project separately and deal with multiple revision numbers. If there are pieces of this that make more sense to be filed against Subclipse, I'd be happy to do so.
You would have to fill it not just against Subclipse but on Platform/Team (and CVS) component.
Changing OS from Mac OS to Mac OS X as per bug 185991
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
