Hg does support merging between branches of course and being changeset-based, it is very efficient, sending only the changesets not already present in the target repository.

When merging, the changesets are merged first in a temporary head or internal branch in the repository. Then, it is merged with the working directory data either automatically (through hg pull -u) or manually (with hg update or hg merge).

That is done this way to reduce potental conflicts because upstream code is less likely to generate conflicts than local modifications.

You can also have multiples heads within an Hg repo without merging and it could be used for internal branches without going through a complete clone.

See [“VCSFeatureBranch”] and [“VCSFeatureVendorBranch”]

Supported (also see [http://venge.net/monotone/wiki/FeatureMerging monotone:FeatureMerging])

Monotone has very robust and powerful merging capabilities, which work based on the [http://en.wikipedia.org/wiki/Directed_acyclic_graph DAG] history structure, independent of branches. These capabilities work regardless of how developers choose to use branches.

The merge, propagate and explicit_merge commands all access the same underlying merging capabilities, and differ only in how they select the revisions to be merged. merge picks multiple heads of the same branch, propagate merges the changes along one branch into another, and explicit_merge lets you pick whatever you like.

A very common developer loop:

<edit files>
$ mtn commit
$ mtn pull
<new revisions incoming>
$ mtn merge
$ mtn sync
<local commits and merge node(s) outgoing, maybe more revisions incoming>
$ mtn update