Local Mercurial repositories on top of other SCM systems

Hi everyone,

Big fan of Mercurial here. Enough that going to other SCM systems is seen as an unfortunate experience. For example, where I worked as an intern we use TFS. Now TFS is much more than source control but I personally don't like its approach to the source control aspect (also: I'm starting to dislike source control plugins to the IDE, but that's another day).

One of the policies is that every commit must have a separate code reviewer. That's fine, but for me made commits a hassle, especially since I started working outside normal hours (and was given limited commit access in the beginning as an intern).

Anyway, the solution is simple: I create a local Hg repository in the directory the project's checked out in and commit to that instead. Also be sure to clone it to a not-your-desktop-which-could-randomly-explode location.

The good news is that this is a very simple process. The bad news is that you of course don't gain the advantage of keeping the Hg commit history like you would with a more complex tool for this like hg-svn or something. Of course in my situation that would get the same problem of requiring reviewers.

The main use for this was to be able to commit frequently and have snapshots of the progress instead of having to, for example, shelve it in TFS. As long as you make sure to clone it somewhere that's not your local machine as well, you should be good to go.

Another time this makes sense is where the rest of your team is used to SVN and the learning curve of another source control system is too much of a pain right now.

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. 

Forcing mandatory unit tests when pushing to the central repository

For the past few days I've been working on getting our build process automated to deploy to a local server (since we have no remote host as of yet). It's deceptively simple:

1. build java source files (including tests)
2. copy compiled class files to deploy directory

Sounds easy, right? It should be, but my relative inexperience with web apps translates into spending extra time configuring environment variables, searching out libraries and putting them in the right place, etc. But hey, that's finished now!


The real issue I wanted to tell you about is related: We want to make sure our unit tests are run each time someone tries to push to the production branch of our central repository, to make sure they haven't broken. I figure we also want to test them outside are local environment, let's say the directory of the local server we test on.
So we add a preoutgoing hook to mercurial that simply launches an ant script that will run the unit tests and the push will fail if the tests fail. To get this working though, my process resembled this less-than-ideal workflow:

1. build java source files (including tests)
2. copy compiled class files to deploy directory
3. call junit task from within Ant
4. Observe that _x_ is not in the right place
5. Put _x_ in the right place
6. Repeat

Where _x_ usually refers to hibernate and one of its xml files. Figures. However, after hours of pain and realizing that I had pointed the ant script to the wrong version of Tomcat, this process now resembles the ideal process at the beginning. I'm pretty happy with it, I just hope it continues to work...