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.

Multiple heads of the same branch using Mercurial

(No progress on the chemical structure tool -- I've been working on my Other Project)

Anyway, today I'd like to tell you about one of our recent problems that we had to overcome using Mercurial. Mostly for reference purposes so I don't forget about the solution, but if you find it useful that's great.

So, we've been using Mercurial for a few months now, and I personally like it a lot. However, that doesn't mean we've been without our share of "learning experiences." Recently we discovered how important it was to pull before pushing changes on a commonly worked on branch (in this case, it's our Test branch).

Since this branch gets merges from our development branches quite often, there's no guarantee that you have the most up-to-date version when you're merging with it. So one of our philosophies is to just always pull before merging anything.

Now what happens when you don't do this? Well, let's look at our scenario:

• Changes are merged into Test and pushed to the remote repository from machine A. Everything's OK 
• Machine B also merges changes into Test but does not see machine A's changes on Test.
• Machine B attempts to push, Mercurial warns that there will be two heads on the Test branch. Otherwise it would have to decide whose changes are the "official" ones, and that's not it's problem. 
• Machine B then pulls and observes multiple heads on the Test branch. 

Oops. Now, back when we were working on a group project for school, we had this problem but I didn't understand it enough to fix it. This time however, we fixed it and now it's just an inconvenience. We pull the changes on machine B so we see the multiple heads, and just merge one head into the other. Problem solved!

And everyone's happy!

Now, I'm sure some of you are thinking "duh, Chris, what's so hard about that?" Sorry guys, I'm still working on a complete understanding of Mercurial. But that's one less step we have to deal with 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.