• Choose a category
• All
• Classic-Fiction

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

Afterwards, if someone needs to work on a bug fix that ought to go into an upcoming 1.0.1 minor release, they clone the myproject-1.0.1 repository, make their changes, and push them back.

$ hg clone myproject-1.0.1 my-1.0.1-bugfix

updating working directory

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ cd my-1.0.1-bugfix

$ echo 'I fixed a bug using only echo!' >> myfile

$ hg commit -m 'Important fix for 1.0.1'

$ hg push

pushing to /tmp/branch-repo8ztZpS/myproject-1.0.1

searching for changes

adding changesets

adding manifests

adding file changes

added 1 changesets with 1 changes to 1 files

Meanwhile, development for the next major release can continue, isolated and unabated, in the myproject repository.

$ cd ..

$ hg clone myproject my-feature

updating working directory

2 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ cd my-feature

$ echo 'This sure is an exciting new feature!' > mynewfile

$ hg commit -A -m 'New feature'

adding mynewfile

$ hg push

pushing to /tmp/branch-repo8ztZpS/myproject

searching for changes

adding changesets

adding manifests

adding file changes

added 1 changesets with 1 changes to 1 files

Don’t Repeat Yourself: Merging Across Branches

In many cases, if you have a bug to fix on a maintenance branch, the chances are good that the bug exists on your project’s main branch (and possibly other maintenance branches, too). It’s a rare developer who wants to fix the same bug multiple times, so let’s look at a few ways that Mercurial can help you to manage these bug fixes without duplicating your work.

In the simplest instance, all you need to do is pull changes from your maintenance branch into your local clone of the target branch.

$ cd ..

$ hg clone myproject myproject-merge

updating working directory

3 files updated, 0 files merged, 0 files removed, 0 files unresolved

$ cd myproject-merge

$ hg pull ../myproject-1.0.1

pulling from ../myproject-1.0.1

searching for changes

adding changesets

adding manifests

adding file changes

added 1 changesets with 1 changes to 1 files (+1 heads)

(run 'hg heads' to see heads, 'hg merge' to merge)

You’ll then need to merge the heads of the two branches, and push back to the main branch.

$ hg merge

1 files updated, 0 files merged, 0 files removed, 0 files unresolved

(branch merge, don't forget to commit)

$ hg commit -m 'Merge bugfix from 1.0.1 branch'

$ hg push

pushing to /tmp/branch-repo8ztZpS/myproject

searching for changes

adding changesets

adding manifests

adding file changes

added 2 changesets with 1 changes to 1 files

Naming Branches Within One Repository

In most instances, isolating branches in repositories is the right approach. Its simplicity makes it easy to understand, so it’s hard to make mistakes. There’s a one-to-one relationship between branches you’re working in and directories on your system. This lets you use normal (non-Mercurial-aware) tools to work on files within a branch/repository.

If you’re more in the “power user” category (and your collaborators are too), there is an alternative way of handling branches that you can consider. I’ve already mentioned the human-level distinction between “little picture” and “big picture” branches. While Mercurial works with multiple small-picture branches in a repository all the time (for example after you pull changes in, but before you merge them), it can also work with multiple big-picture branches.

The key to working this way is that Mercurial lets you assign a persistent name to a branch. There always exists a branch named default. Even before you start naming branches yourself, you can find traces of the default branch if you look for them.

As an example, when you run the hg commit command, and it pops up your editor so that you can enter a commit message, look for a line that contains the text HG: branch default at the bottom. This is telling you that your commit will occur on the branch named default.

To start working