Monthly Archives: May 2014

Rapidly Changing Between Mercurial Clones. Or, How I Went Crazy with Mercurial Power.

Update: To be clear, the below “solution” is not recommended.  This is just me fooling around with Mercurial, and being impressed with just how well it worked anyway.  Instead, please compare the different approaches to branching in Mercurial, and choose something well accepted.  Consider reading A Guide to Branching in Mercurial

The coding environment at my work makes heavy use of Mercurial clones to manage changes in team development.  If you’re going to fix a bug, or add a feature, you clone the production repository and place all of your code in the clone.  Continue forking as needed.

Repo Figure 1

The reasoning here, is to allow developers to maintain different branches, while simultaneously making QA easy.  See this workflow.

Also, note that the “Sub Feature” repositories are a little extreme.  It’s typically just the one level with separate repos for entire features and bug fixes.  The only time you see more levels is when there’s a whole team working on an individual feature and they want a shared repository to merge their stuff before it goes up the chain any further.

The main issue with a cloning work culture vs inter-repository branching or merely attaching patch files to the issue tracker, is that it’s tedious to manipulate your working directory that your IDE points to.  When I finish one bug, and am now onto the next, I have to somehow point Eclipse at the new source folder.  Or, I have to swap the source folder out with the new clone’s tip so I can begin working.

The reason for that is we have to keep our fixes / features isolated from one another, we don’t know which work effort will get past QC and into stable.  So by keeping them isolated, the build manager can instantly blow away the QC merge and make a new one with a new set of fixes and features added in.

Well, I didn’t want to point Eclipse to a new source folder each time, there’s no easy built-in way to do that.  I also didn’t want to manually swap out the code from one repository for another.  I wanted a quick and easy way.

My first thought was that since the the entire repository is inside the .hg folder, I could simply zip it up, place the .hg folder from the new repository in it’s place, and do a clean update to get the working directory in proper order.  It worked ok…. kind of.

Each time I wanted to work inside a different clone, I would have to do the following (after I acquire the new clone’s .hg folder):

  1. Zip up the current .hg folder to something like .hg.stable.7z
  2. Delete the current .hg folder
  3. Place the new .hg folder in place of the old

But then I had a crazy idea!  What if I use Mercurial to place the .hg folder itself under source control?!  That’s just too crazy, right?  Nested source control?  I agree, it’s strange.  But it actually works pretty well.  In the nested repository, I control the former via branches.  So I have a branch that tracks stable, one that tracks an individual bug, etc.

This allows me to essentially (and invisibly) force the workflow of branching into one of cloning-only.  A quick update and my work repository is at the state I want it to be in.

In practice the repository that controls the other ends up looking like this:

Repository repository

So when I am supposed to fix a new bug, and keep my changes isolated in a new clone, I can use this repository to revert the other one back to stable, do my work, commit it, and then come back to this one, and commit the repository itself into a new branch.

You can see in the image above where I’ve done that numerous times.  It splits off.  I can also quickly revert back if I want.  For example, if I ever get around to finishing that JSF and Richfaces Upgrade.

I still believe this is crazy, but it’s just the point I’m currently at on my quest to find the best way to go about this whole thing.  It’s fun to experiment.

repository new files at point