I had something of an epiphany this morning. If it wasn't the real thing, it sure felt like it. With Eclipse, I'm often trying out new plugins that purport to do one other or another, and there are usually a few that do the same thing, but with different features. So the quandary is, what do I do when I pick one of the several, try it, and don't like it? Perhaps it's hard to use, perhaps my IDE crashes more often than it used to, or perhaps one of the other similar plugins suddenly seems more appealing.
Traditionally, I've solved the problem using rsync. I rsync -a eclipse/ eclipse.beforeWonderfulPlugin, then install the plugin. If the plugin turns out to be a flop, I go back to the old version, which takes a little while. First, delete eclipse, then rsync -a eclipse.beforeWonderfulPlugin/ eclipse. It's slow, but it easier and faster than say, cp or tar. Also, I now have (at least) two entire copies of eclipse laying around.
There are further issues, too, though they're perhaps less important. It's hard to remember what plugins I have installed, for example, above and beyond what's already included.
Lately I've making the move to git to manage source for various projects. Then it hit me - I should make my Eclipse install a git repository. So that's what I did. There's a master branch - that's where the downloads from Eclipse go - ganymede->ganymedeSR1->ganymedeSR2, and so forth. Then, there's the working-branch, which is where I'll normally run from. When I'm trying a new plugin, I'll branch off of working-branch, try the plugin for a while. If it's good, I'll merge it back into working-branch.
Presumably, there will be an Eclipse Ganymede SR3 at some point, and I'll rebase there. When Galileo comes out, I'll put that on master, and probably start a new working-branch.
If I merge a plugin into working-branch, and find out a week later that there's a problem, it's easy to re-branch from a point prior to the merge, and get rid of the plugin. Sometimes it's the case that there's some quirky behavior I didn't notice at first. It's a matter of a few minutes to go back to a previous version, try it out, and see if the quirky behavior was there all along, or started with some new plugin.
Sure, Eclipse lets you uninstall plugins, most of the time, but there are often problems with that.
Could this be done with CVS, Subversion, ClearCase or other revision control systems? Very possibly - but not in practical terms, simply because of the performance issues.
If there are alternative plugins, say, Subclipse and Subversive, and I want to try them both, I can have them both on separate branches off of working-branch, and explore them both for a while before picking one. As an added bonus, gitk lets me see where I've been, and when I started using which plugins.
5 comments:
Although still imperfect eclipse's provisioning system (p2) is supposed to solve this problem for you.
I haven't looked at it. So, I suppose you're saying that it solves the problem of installing/uninstalling? Or does it also allow for the tracking and switching between feature sets, etc.?
Also, this approach should allow me to upgrade to point releases of Eclipse and rebase.
p2 is supposed to be a central repository for all eclipse-related stuff. Its supposed to be able to manage feature sets as well as point releases of eclipse. You're supposed to be able to manage all of your eclipse installs, across point releases, with a single p2 instance.
But like I said, there are kinks in the system, and your way is dead simple.
Hey, if there's one thing I know, it's dead simple.
Post a Comment