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

[peter at peterkellner.net]

Thanks Adrian,  this is a big help.

-----Original Message-----
From: Adrian Buehlmann [mailto:adrian at cadifra.com] 
Sent: Saturday, January 22, 2011 12:09 AM
To: peter at peterkellner.net
Cc: mercurial at selenic.com
Subject: Re: I'm using tortoisehg and am a little confused on a workflow for branching.

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