Workflow for working with two versions of a project in Mercurial

Question

I have an application that is version 1.0. I now need to start work on version 2.0 but at the same time maintain and fix bugs in version 1.0.

Bug fixes from 1.0 will be merged into the 2.0 release but no new functionality will be backported from the 2.0 to 1.0 release.

I understand how branches work however I need to be able to work on both versions at the same time so switching between branches in the same working folder isn't practical. I want to be able to run both versions of the code at the same time.

What is a typical setup or workflow for being able to work on two versions of the same application using named branches at the same time? i.e. working with one branch in one folder and another branch in another folder?

Do I just clone the repository into a new folder for version 2.0 and set the branch to the one for the 2.0 release?

I'm a bit new to Mercurial so please forgive me if this sounds a bit naive.

Answer 1

Do I just clone the repository into a new folder for version 2.0 and set the branch to the one for the 2.0 release?

Yes, a separate clone for each major release will just fine. However, you should keep your main development on the default branch and use named branches for each major release. Let me run through the workflow:

When your version 1.0 is done, you do

$ cd ~/src/foo
$ hg tag 1.0
$ hg push http://your-server/foo

and you can then continue working in that clone towards version 2.0. When you find that you need to fix a bug in 1.0, you do

$ cd ~/src
$ hg clone http://your-server/foo foo-1.x
$ cd foo-1.x
$ hg update 1.0
$ hg branch 1.x
$ hg commit -m "Starting 1.x branch"
# now fix the bug... left as an exercise to the reader :)
$ hg commit -m "Fixed issue123"
# do QA to test the bugfix, make more commits as necessary
$ hg tag 1.1
$ hg push --new-branch
# make a release

The --new-branch flag is only necessary the first time you push. It tells Mercurial that you really do want to create a new permanent branch in the history.

You now want to pull the bugfix into the other repository:

$ cd ~/src/foo
$ hg pull http://your-server/foo
$ hg merge 1.x
$ hg commit -m "Merge with 1.1"

By using a named branch for the 1.x series, you can always use hg update 1.x to go to the latest changeset on that branch. Think of 1.x as a "floating tag" that always point to the tip-most changeset on that branch.

This workflow is described in the standard branching wiki page.