Pitfalls of Mylyn

If you don't know, Mylyn is a plugin for the Eclipse IDE that provides a task-oriented view of the IDE and helps automate a few tasks. It integrates with your project tracking tools, like Trac or Bugzilla, so you can get a list of the tasks (a generic word for tickets or bugs) that you need to work on right there in Eclipse. You activate one of the tasks, and Mylyn will automatically restore the IDE to the state it was at when you left that task by:

• Opening the files you were working on
• Changing the perspective, if necessary
• Limiting the navigator to show just the files falling inside the context of the task

As you work on the task, it keeps track of which files you access (even those you just view) and adds them automatically to the context of the task. When you're done with the task, you can attach the context as a .zip file to the ticket so another developer would be able to reference it later.

That's a short overview of some of the handy features of Mylyn that I use. As I've used it over the last few months, I have discovered two issues that I would like to detail.

First off, the task context will absorb any files that are touched by a SVN snychronize or SVN Update. When working in a team development environment, it's best to update your local working copies frequently to receive the latest code updates from the rest of the team to avoid any integration issues. Eclipse makes this easy by allowing you to schedule a refresh of the synchronize view, which will alert you to any incoming changes. However, any file identified to have incoming changes during a refresh of the scynchronize view will be added to the context of the active task. Additionally, if you perform a SVN update while a task is active, any files updated will also be added to the context of that task. I consider this to simply be a bug in Mylyn; it is needlessly adding files to the context of the task, to the point where the context becomes so bloated it is useless. There are really only two options for maintaining your task context:

• Deactivate the task before any SVN operations (which is hard to do if you are using the scheduled refresh of the synchronize view).
  
• Constanly remove extra files from the context.
  

The second issue is a by-product of what is really very useful feature that Mylyn provides: the commit comment template. This feature allows you to set up a default format to use for the comment when commiting code that can automatically insert properties of the active task. For example, you could set it up to default to "Refs [insert ticket number here]". This is especially handy when you are using the trac-post-commit-hook in your subversion repository to automatically update the ticket when you commit a revision for it, because you don't accidently mistype a commit comment and fail to trigger the hook.

The problem comes when a developer uses this template to completely formulate their commit message and fails to provide any additional information about the specifc changes they are committing. If a ticket ends up with several revisions, and you ever have to review those reivisions, you end up looking at a list of revisions with exactly the same comment. Not very helpful. This is purely a case of developers being too lazy to properly document their revisions (the infamous "lack of documentation" problem), but I would nevertheless categorize it as a potential pitfall of using Mylyn. It is not a reason to avoid using Mylyn in of itself, but it is something to be aware of and instruct your team to avoid.