Version Control: MercurialEclipse and ... Eclipse

Alright. I love Mercurial. I admit, I was an advocate of Subversion on solo projects (and actually, it's still good for solo projects) but when I started working with a team, I ditched SVN in favor of Mercurial.

Now I'm not trying to just blindly jump on the DVCS bandwagon here, and I'm not going to try and convince anyone. However, having used both SVN and Mercurial on a Windows system, I prefer Mercurial. So naturally on my latest collaborative project we decided to go with Mercurial. Since we're developing in eclipse, we decided to use the MercurialEclipse plugin.

For the most part, it's working quite nice. We've come up with this structure where we each have our own development branches, and then a test and production branch. We try and interact only through the Test branch so we can have our own changes going on in other branches. And it works most of the time.

Unfortunately, it's that other 10% of the time that causes us 80% of the headaches. Now we're probably doing something wrong, but early on in the project an Eclipse .classpath file got committed into the repository and has caused us our share of pain. The .classpath file contains all of the included libraries for each project. So here are the things we've experienced:

• conflicting .classpath files get committed since we have different workspaces
• attempting to ignore/delete the .classpath file from the repository results in its deletion  from the file system. Oops. 
• switching branches sometimes results in .classpath problems. 

Actually, these problems are a function of our workspaces being different. So we changed that:

• Our workspaces are now the same
• We use relative file paths for including *.jars 
• We once again commit the .classpath file to the repository

The difference now is that the .classpath file is the same for everyone, so we no longer experience headaches caused by having different paths.