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):