Community
Participate
Working Groups
We have had this request in Subclipse before, and it occurred to me that Mylar might also be a good candidate to add this. Anyway, in the list of variables for the commit comment template, it would be useful to add some variables related to the content being committed. A lot of projects seem to like the user to list the files being changed, with some comments for each change. At a minimum, I am thinking you would want a variable for the filenames, but if you have the information, an option to also include method names would be nice. For filenames, I could see having more than one variable. One that was just the filename, and one that was the project relative full path name.
Hmm. Wouldn't it be strange to have filenames in the commit message if version control system can tell you those names anyways. I wonder if some textual digest of the task context would make more sense.
A lot of projects, Subversion being one, require it. I think the core Apache httpd/apr projects also use the same convention. Brings up another item and that is that the commit message template ought to be configurable at the project level to account for different formats used by different projects.
Interesting. Seems like a CVS legacy. Anyways, we have bug 150663 requesting commit templates to be repository specific and been waiting for input.
Mark: in terms of implementation this template should be quite easy to write, since we would just ask the outgoing change set for all of its files. But I'm surprised that projects make this a convention since this is the main thing that the version control system is responsible for. Is it to help QA people or something of that sort? So are you proposing variables like ${task.changeset.files.names} and ${task.changeset.files.paths}? I guess it's OK to blow up the commit message if the user explicitly indicates that they want this.
As Eugene says, it might just be a CVS legacy. The Subversion project itself requires this, and I believe they got their styles from the Apache httpd project. Most of the Subversion-related projects seem to follow it too. I think a lot of Subclipse users must use it because we had a lot of requests for features like running compare from the commit dialog so that the user can write detailed info about what they changed. I think what you proposed would be fine. I assume that the file names variable would give just the file name (Plugin.java) and the paths variable would give the full project relative path (src/org/eclipse/mylar/Plugin.java). I have linked to an example of messages used by the Subversion project. Anything you can do to get the user 50% of the way to having the message in this format would be useful. http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_fs_util/?view=log
We will most likely need a contribution for this to be added to the 2.0 plan.
I asked one of the SVN developers why they require such detailed log messages. It turned into a blog posting: http://blogs.open.collab.net/svn/2007/05/the_subversion_.html
Personally, I would need a lot this feature for Bugzilla comment committing, too. I think it would be a nice feature if Mylyn remembered all the resources that were modified within a context, so that you can commit it to Bugzilla, when you close a bug for instance. This is would be useful for our development team. It could be a good compromise if you had to do this before commiting the associated changeset, though, if it is easier to implement. I know this is not 100% related to this enhancement request, if you feel I should better open a new one I'll do. Mauro.
Mauro, affected/interesting files should be available from the context attached to the bug report. Though it won't show what files had actually been changed. I opened bug 197316 to cover that (it could be a duplicate).
Dear Eugene, this is not exactly what I would need, because some changed files may not be still "interesting", either because you modified them a long time ago or because you closed the corresponding editor. I would need a list of ALL modified files, even if they are not "intersting" any longer.
Tree is already virtual, however it is not free to create a sorted and filtered model with few thousand children. I see that archive node expands faster when I filter out completed tasks from the view menu. The only option I can think of is to move logic with regexp right into the abstract task instance, so it will be possible to cache it, instead of recreating groups on every comparison. This is the stack trace (very hard to catch): "main" prio=6 tid=0x00296000 nid=0xe9c runnable [0x0090e000..0x0090fe5c] java.lang.Thread.State: RUNNABLE at java.lang.String.length(String.java:652) at java.util.regex.Matcher.getTextLength(Matcher.java:1140) at java.util.regex.Matcher.reset(Matcher.java:291) at java.util.regex.Matcher.<init>(Matcher.java:211) at java.util.regex.Pattern.matcher(Pattern.java:888) at org.eclipse.mylyn.internal.tasks.ui.views.TaskKeyComparator.split(TaskKeyComparator.java:52) at org.eclipse.mylyn.internal.tasks.ui.views.TaskKeyComparator.compare(TaskKeyComparator.java:23) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListTableSorter.compareElements(TaskListTableSorter.java:139) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListTableSorter.compare(TaskListTableSorter.java:107) at org.eclipse.jface.viewers.ViewerComparator$1.compare(ViewerComparator.java:187) at java.util.Arrays.mergeSort(Arrays.java:1293) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1282) at java.util.Arrays.mergeSort(Arrays.java:1281) at java.util.Arrays.sort(Arrays.java:1210) at org.eclipse.jface.viewers.ViewerComparator.sort(ViewerComparator.java:185) at org.eclipse.jface.viewers.AbstractTreeViewer.getSortedChildren(AbstractTreeViewer.java:604) at org.eclipse.jface.viewers.AbstractTreeViewer.updateChildren(AbstractTreeViewer.java:2497) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefreshStruct(AbstractTreeViewer.java:1826) at org.eclipse.jface.viewers.TreeViewer.internalRefreshStruct(TreeViewer.java:692) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1801) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1757) at org.eclipse.jface.viewers.AbstractTreeViewer.internalRefresh(AbstractTreeViewer.java:1743) at org.eclipse.jface.viewers.StructuredViewer$7.run(StructuredViewer.java:1433) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1368) at org.eclipse.jface.viewers.TreeViewer.preservingSelection(TreeViewer.java:378) at org.eclipse.jface.viewers.StructuredViewer.preservingSelection(StructuredViewer.java:1330) at org.eclipse.jface.viewers.StructuredViewer.refresh(StructuredViewer.java:1431) at org.eclipse.jface.viewers.ColumnViewer.refresh(ColumnViewer.java:503) at org.eclipse.ui.dialogs.FilteredTree$NotifyingTreeViewer.refresh(FilteredTree.java:818) at org.eclipse.mylyn.internal.tasks.ui.views.TaskListView$10$2.run(TaskListView.java:860) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:123) - locked <0x04239c80> (a org.eclipse.swt.widgets.RunnableLock) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3659) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3296) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2389) ...
Please ignore last comment. Wrong bug report
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
