An often-overlooked feature in Eclipse 3.2 is support for Change Sets in the Team functionality. What are Change Sets, you ask? Well, picture this oft-occurring developer scenario:You’re in the middle of working on an import feature (aren’t they all?), let’s call it FeatureX, happily coding away and hoping to be awarded FeatureImplementorOfTheYear, when suddenly an “emergency issue” is dropped into your lap. You have to drop everything you’re working on and attack this Feature Y. But here’s the problem: you’ve modified 20 source files already, and they’re not ready to check in! Implementing this “Emergency issue” is going to require modifying another dozen or so files and when it comes time to commit your FeatureY, how do you remember which files were modified for which feature?
Here you have a few possibilities:
- Checkout a new copy of your branch from CVS/SVN and implement FeatureY on that local copy (not very efficient).
- Write down or otherwise commit to memory every file you changed for FeatureX and every file for Feature Y, then make sure you only commit the right ones when it’s time to do so. (good luck!)
- Use Eclipse’s “Change Set” functionality to “tag” the files for FeatureX and don’t worry about them – Eclipse will remember them for you!
Here’s how it works:
- Before you start work on Feature Y, perform a Synchronize on your Project(s). Select “outgoing mode” and click the little button on the the right of the Synchronize toolbar to enable Change Sets (it’s greyed out if you’re in “incoming/outgoing mode”, and don’t even think about using it for “incoming” mode because it will take forever).
- Select the files that were modified for FeatureX, then right-click them and select “Add to… New Change Set”. In the dialog box that pops up, give the change set a name (say, FeatureX), and if you like, give it a CVS commit message, then press OK.
- Notice that Ecliipse has now segregated your Synchronize view to show files that are part of your new Change Set independently of the Project’s other changes (if any).
Now you can merrily go about working on Feature Y, content in the knowledge that next time you do a Synchronize, as long as your implementation of FeatureY didn’t modify the same files as FeatureX then Eclipse will keep track of which changes belong to which feature.
Change sets aren’t perfect, and they’re not the right tool in all cases, but sometimes they’re just what a time-crunched developer needs.
Subscribe by RSS
Great feature! The thing that hits me though, is that I set up a very, very large changeset.. and it intermittently disappears.
Where is the change set information stored? What actions can potentially remove them? In my case, I often close and re-open projects within the workspace..
Change sets often look like they’ve disappeared when you’re viewing the “incoming/outgoing” mode.
Another thing I forgot to mention is that if you choose to commit an entire change set through the “synchronize” view then eclipse seems to decide that you’re done with the change set and it disappears.
Unfortunately, I haven’t had time to look into where the change set information is stored, or what all the different actions might be that could remove change sets.
If you think the idea behind change sets seems like it would be helpful but you want more flexibility, then you might want to look into a more full-featured plugin such as Mylar (http://www.eclipse.org/mylar/).
I like the changeset functionality too.
I just wish there was an easier way to test the changesets independently. Currently I test ALL my changes locally, then check in a changeset and depend on an automated build server to tell me if I missed something.
Usually the local testing works, but there have been cases where there was subtle dependencies between my changesets and the build on the build server failed. Of course in those cases I do analysis and fix the problem. But firstly, not everybody has automated build servers. And secondly, it would be nice to be able to test before committing so you do not break the build.