Tag Archives: source control

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

Know Your Tools: A Crash Course on Mercurial Patch Queues

Imagine that you just made and committed a new feature, and are halfway through your next super awesome feature when catastrophe strikes!  There’s something wrong with your previous feature that was just committed!  What do you do with your current uncommitted work?  You could shelve it, you could create a separate repository, or you could simply carry on and make note of the problem, promising to fix it later.  You have numerous options.

Let me introduce you to another option: “Mercurial Patch Queues!” he shouted with unmatched enthusiasm.

If you had done this local work as patches instead of commits, you could turn your unfinished working directory changes into a new patch, pop it off the applied stack (out of the working directory), fix your previous patch, re-apply the working directory patch, and then carry on with the work you were in the middle off.  Since you modified the patch itself, it’s as if your work was extra perfect the first time around.

In general, making use of these patches will allow you greater control over your changeset history.  You can think of it as a private mutable history that you’re free to manipulate however you like before you transform it into the normal shareable state.  Allowing you to get your changes just right before committing them, but still giving you advantages of source control.

Another use-case would be temporary “checkpoints”.  Let’s say you’re coding, and you want to save your current state, to protect yourself from future blunders, but this effort isn’t done yet and you don’t want to pollute the changeset history with numerous commits.  You want one commit that contains all of your related work.  For this, you can create a patch of the working directory.  If you’ve made a patch, and then later screw up, you can revert your code to the patch, just like you would a previous changeset.  So if you screw up later, you can revert to the patch that was made and try again.


Enabling the Extension:

In your mercurial preferences file: add

hgext.mq =

And then check it’s working with “hg help mq”

C:UsersmurchDesktopNew folder>hg help mq
mq extension - manage a stack of patches

This extension lets you work with...
Creating a Repository With a Patch Queue – “hg init –mq”:
  1. hg init (if it’s already a repository, skip to step 2)
  2. hg init –mq (Two dashes.  Enables the patch queue functionality in the given repository)
Creating a New Patch – “qnew”:
  1. hg qnew patchname.patch
Update the Patch With Your Work – “qrefresh”:

After making some changes in your working directory, you can use qrefresh to update the topmost patch so that it represents all of your changes.

Note: If your change includes things such as adding a file, you still use the same “hg add” command and then you would use “qrefresh”, so that the change in the patch is “add this file with these contents”.

If you want to apply the changes to a patch that isn’t the topmost patch, you can simply make use of qpush and qpop until the desired patch is at the top of the applied patch stack, and then use qrefresh.

Note: Try to rearrange the patch stack before you make your local changes, otherwise when you go to rearrange with qpop and qpush, you’ll get a message like so: “abort: local changes found, refresh first”.  You can force the operation with the -f flag, if you really need to.

Manipulate the Patch Stack – “qpop” and “qpush”:

When working on multiple simultaneous patches, these allow you to manipulate the currently applied patches in your working directory: qpop takes the latest applied patch out of the working directory, and qpush will apply the most recently popped patch back into the working directory.

Make use of the -a flag to push or pop all patches.

Delete an Unwanted Patch – “qdelete”:

You can use qdelete to delete an unwanted patch by name.

Convert a Patch Into a Normal Mercurial Changeset – “qfinish”:

You can use qfinish to convert an applied patch into a normal revision in the changeset history.

Convert a Changeset Into a Patch – “qimport”:

The exact opposite of applying a patch to the changeset history is to take a specified revision and convert it into a patch.  You can do this with qimport.

Note: You can only do this if Mercurial considers the changeset to be mutable.  Which more or less means you haven’t sent that changeset off anywhere, such as with a push.

Sources and Further Reading:

(HG Book – Managing Change with Mercurial Queues) http://hgbook.red-bean.com/read/managing-change-with-mercurial-queues.html

(Why would I want to use MQ?) http://mercurial.selenic.com/wiki/MqTutorial#Why_would_I_want_to_use_mq.3F