7 Project-saving Source Control Tips for the Eclipse IDE
In only two seconds, just one developer with poor source control habits can cost the entire team hours of debugging. Fostering these seven simple steps for yourself and your project teams will save time and frustration while improving quality.
Tip 1: Use a Plugin
When I first started using Eclipse the company source control system was Microsoft Visual Source Safe (VSS). The VSS fat Windows client at the time was very easy to use, but it was very tedious to go back and forth between Eclipse and VSS, then navigate the source tree (again, having already done it in Eclipse) to find the file and check it out. I was already in the process of building out an Eclipse toolkit for myself, and decided early on that a VSS plugin was a must-have. The plugin allowed me to check files in and out without having to leave my development environment, and I could even configure it to remind me to enter check-in comments every time.
The Eclipse source control plugins have evolved to the point where you may never need to install anything else on your machine to use all the features of your source control application of choice (or your company's choice). In fact, many of the source and version control vendors' fat clients are Eclipse based (though the plugin is usually much less resource intense).
Below are links to the plugins I have used most often, though there are others available for these source control vendors and others not included:
Tip 2: Start Every Day Fresh
Agile methodologies that include continuous integration strongly advocate that source control be directly integrated within the IDE, as is achieved by using a plugin for source control. Without this integration, many developers tend to let their local environment become out of sync with the full project source. All it takes is for a developer to miss a one-method signature change before checking in dependent code to lead to an all-night debug session.
Starting every day by getting the latest code from source control won't eliminate the need to chase down the results of a missed change, but it will greatly reduce both the frequency and impact of missed changes. You can also go one step further and get the latest of all code that is related to anything you are working on at the time you begin working on it. This way, you actually can completely eliminate this potential pitfall.
Tip 3: Never Put Off to Tomorrow What You Can Check In Now
After you and your team have developed the habit of getting the last code at least daily, things can go wrong only when the latest code isn't in source control. Just as the ancient computing phrase "garbage in, garbage out" is still true, the more esoteric phrase "you get back what you put out" still relates to software development. So if you are getting the latest from source control at the start of every day (or more), you should check in the latest source at the end of every day (or more). The best habit is to check in code every time it both compiles and unit tests without breaking anything.
At the very least, everything should be checked in before logging off for the day. Many developers use the excuse that something is incomplete and cannot be checked in, but if the code changes are so sweeping that the incomplete code cannot be either commented out or saved locally to a temporary file while the original code is rolled back, then the odds are very good that the code has also become out of sync with the full project source (or will become so soon). The "not done yet" excuse has resulted in developers becoming days out of sync with the project, and almost always takes a long time to integrate back in.
And not to be too morbid, but there is also the "what happens if you don't show up for work because you [enter unpleasant scenario here]" consideration. Being courteous about source control is just as important as other courtesies.
Tip 4: Use Check-in Comments
I admit, this is a habit I need to work on myself. While it is easy to think "if someone wants to know what changed they can just run a diff," the truth is that it is much easier for them to just read the comment that the previous developer courteously added when they checked in their changes. Also, the value of the check-in comment is not so much for the one version change, it is often a huge time saver when you go back five or six iterations and wonder why you yourself made a particular change.
Page 1 of 2