I'm using tortoisehg and am a little confused on a workflow for branching.

[Adrian Buehlmann]

On 2011-01-22 05:11, peter at peterkellner.net wrote:
> We have 3 dev’s and we all check into the trunk

Mercurial's "trunk" is the default branch. It doesn't show up as a
branch name on changesets when e.g. using 'hg log', because every
changeset by default is on the default branch.

You see it when you create a new repo

  $ hg init repo1
  $ cd repo1
  $ dir /w
   Volume in drive C has no label.
   Volume Serial Number is F80E-0A52

   Directory of C:\Users\adi\hgrepos\tests\repo1

  [.]   [..]  [.hg]
                 0 File(s)              0 bytes
                 3 Dir(s)  437'560'950'784 bytes free
  $ hg branch
  default

> and sync and merge with
> our bitbucket repository practically every commit.  I want to have one
> of the dev’s

Let's call him dev C

> start working on new stuff that would break everyone’s
> build if he were to check it into the trunk.

Mercurial (or a DVCS in general) is absolutely perfect for this. State
of the art these days... (not like Subversion).

C can just work in a *separate* repo. Have him start on some convenient
base revision (hg update <baserev>) and let him commit on top of that.
This naturally creates a fork if baserev is not a head.

See http://mercurial.selenic.com/wiki/UnderstandingMercurial

C just must not push to the main team repo and devs A and B should not
pull from C's feature repo.

> I want him to keep his
> stuff up to date with everyone else, but don’t want everyone else to see
> his stuff.

devs A and B should then not pull from C's repo (or from any other clone
he is pushing to while he works on the new feature).

C can have a separate bitbucket repo for the feature while he is working
on it. His local and his bb repo are then short-time forks of the main
repo. The fork has changesets which the main repo doesn't have.

> Then eventually, when his stuff is stable, merge it back into
> the trunk.  I think to everyone else it seems obvious how to do this,
> but I’m kind of lost on this.

dev C just works in his feature repo and regularly pulls and merges from
the main team repo you have at bitbucket, but he should not push to the
main repo until he's finished with the feature.

The main repo is then a subset of C's feature fork. The feature fork has
everything from main but main nothing from the feature fork.

An absolutely classical case for a DVCS.

If the feature fork is mature enough, C does a last final pull and merge
and then pushes his shiny new feature to the main repo.

Or you might not even allow him to push to the main repo and instead
pull what he got.

> Pointers to tutorials, suggestions, crash courses, I’m all ears. I’m
> just having trouble getting the fundamental work flow that I know hg is
> good at working for us.

Alternatively, you can also assign a branch name for working on the new
feature. Martin Geisler has written a nice page "Task Based Development" at

  http://mercurial.aragost.com/kick-start/en/tasks/

for that workflow.

But you should definitely read the Mercurial book anyway:

  http://mercurial.selenic.com/wiki/MercurialBook

There are some other pointers at

  http://mercurial.selenic.com/wiki/BeginnersGuides