darbio

11 July 2012

Mercurial Branching

We are currently going down the path of switching from our huge monolithic SVN repository, to a number of product based Mercurial repositories. Historically, I have used FogBugz and Kiln, but this time we have decided to give the JIRA stack a whirl - mainly for GrassHopper, as one of the project managers here wanted to give it a go.

In the old SVN repo, instead of branching and tagging, we copied files to “Release folders”, and ended up with a bunch of duplicated code, which was pretty hard to manage. One problem was making a bug fix in a release directory, then having to either manually implement that into the development directory, or do an onerous merge of the 2 directories.

To cut a long story short… We were using SVN like a file store, not a source control system.

For my personal projects in KilnHg I have always had 2 repositories per project - one for “Release” and one for “Development”. Why? Because that is how Fog Creek’s guides showed me. It works, but I wanted to take advantage of Mercurial’s named branches for our work projects. It produces some nice graphics, and (whilst I prefer the terminal to work with hg) works better with the TortoiseHg GUI - which is what my developers are used to, albeit TortoiseSVN.

So, I armed myself with some questions:

  • How to do this?
  • What is the best way?
  • Am I mad?

And went to the holy grail of Google to have a look.

After some to-ing and fro-ing, trying and failing, I came up with the following “demo” scenario. What follows is simple, and possibly does not deserve a blog post - but it can provide some point of reference for me (and my team!)…

Initial repository

  1. Create repo in source control system
  2. Clone repo to my machine
    hg clone repoURL
  3. Add my code to the repo
    hg add
  4. Commit code to the repo
    hg commit -m "Initial commit"
  5. Push to the remote repo
    hg push

Make the release branch

  1. Make the release branch
    hg branch "Release-1.0"
  2. Commit the change to the repo
    hg commit -m "Added branch Release-1.0"
  3. Push to the remote repo
    hg push --new-branch

Bug fix on the Release-1.0 branch

  1. Switch working directory to the branch you want to edit in your repo
    hg update "Release-1.0"
  2. Add your bugfix to the repository
  3. Add your changes to the repo
    hg add
  4. Commit your changes
    hg commit -m "Added BUGFIX1 to Release-1.0"
  5. Push
    hg push

Feature added on the default branch

  1. Switch working directory to the default branch
    hg update "default"
  2. Add your feature to the repo
  3. Add your changes to the repo
    hg add
  4. Commit your changes
    hg commit -m "Added FEATURE1 to default"
  5. Push
    hg push

Merge the bugfixes on Release-1.0 into default

  1. Switch working directory to the default branch
    hg update "default"
  2. Merge the Release-1.0 branch into the default branch
    hg merge "Release-1.0"
  3. Commit your changes
    hg commit -m "Merged Release-1.0 into default"
  4. Push
    hg push

Which results in the following graphlog (from BitBucket):


← Back