7 Project-saving Source Control Tips for the Eclipse IDE
Tip 5: Choose the Best Merge Strategy for Your Team
As I mentioned in the first tip, I used VSS in my early days of using Eclipse. On one project there were a couple of new team members who had previously done most of their source control with CVS. The term "check out" has entirely different meanings between those two products. In VSS, it means taking control of the code, which results in the file being locked so that others don't make changes at the same time. In CVS it means getting the latest version of the code from source.
One of the team members with CVS habits thought he was doing exactly as suggested in tip #2 by "checking out" the entire project at the start of the day, and then proceeding to make a large number of changes as part of a proof-of-concept approach. When other team members noticed that all the files were locked by the same person they asked him to check the code back in. Which he did -- all of it, including his changes.
While some products are like VSS, where only one developer can make changes at a time, many products allow multiple developers to make changes simultaneously and then merge the changes together. In the anecdote above, this merge approach would not have worked because the code style of some developers were too divergent from others (which is why it took so long to recover the project).
Some development teams are perfectly in sync with their code styles and continuous communication. For them, doing a merge when they check in their source is a perfect strategy for productivity. This is not true of every team, however. Which is why most of the source control products that allow merging also include the option of turning that feature off, or at least a method to lock a file manually (SVN prompts for a lock comment too, which is actually a good idea). Your team should decide whether merging is a productive approach or not, and then stick to that strategy for the duration of the project.
Tip 6: What Not to Put in Source Control
There are some files in Eclipse projects that do not belong in source control. These files (and entire paths) vary from project type to project type and even more so when you consider all of the vendor-specific versions of Eclipse that are available. There are two simple tests to apply to a file or folder that will cover the majority of projects and vendor versions.
- For Eclipse project configuration files, Does it contain machine-specific values? If it does, it usually should not be in source control. Most configuration files generated by Eclipse use variables that are configured at an IDE level so that the file is portable.
- If the file is generated on every build, the file can usually be eliminated and forgotten about by simply turning off automatic builds and running a clean prior to adding new files to source control. There are some exceptions, such as the
.buildpath, which is emptied but still present after a clean. The
.buildpath never needs to be in source control.
Tip 7: Have a Build Master or Automate Continuous Integration with Larger Teams
While following the first six tips will keep many teams from ever experiencing source control-related issues, there are times when even the most conscientious team members make a mistake or forget to do something. On small teams, following the earlier tips will usually allow the issue to be found and fixed before it causes any real distress. For larger teams, though, it is better to have a way to make sure things don't get too far out of whack and lead to wasted time and lost weekends while tracking down an erroneous bug.
One way to stay on track is to establish the Build Master role and include as a task for that role regular builds (daily, if not more often). The other solution is an automated continuous integration product. There are many such products, and evaluating them could (and may) fill an entire article in itself. Suffice it to say that if your project needs one, it is worth the effort to choose and configure one.
Every developer knows that source control is a necessary part of every project. Now that you have read this article, you have some pointers that not every developer knows -- or at least practices. Hopefully this knowledge leads you to fewer issues and greater productivity.
About the Author
Scott Nelson plays the roles of developer, architect, project manager, server administrator and portal evangelist on any given day, and blogs lessons learned at Head in the Web when it is not suitable for Developer.com articles.
Page 2 of 2