We currently use Subversion and TeamCity, we're going to move to using Mercurial (specifically Kiln as we're FogBugz users).

Obviously this will result in changes - hopefully improvements - in our development patterns (all two of us!) but the one issue I'm stuggling with is how to structure things so that we still enjoy the benefits of continuous integration/our CI server (that there are and will remain benefits is a given, discussion of which is outside the scope of this question).

With SVN we are committing to a limited number of central repositories - effectively one per project (more or less one Visual Studio Solution) so its easy to trigger a build and to get the reassurance that all the files have been commited and that there are no stray dependencies etc, etc. But if we're going to take proper advantge of mercurial we're going to want to have more repository instances - where I'd expect changes to generally flow towards a definitive "live" repo. The problem I'm struggling with is that the live repo seems to me to be too "late" to trigger my CI builds OTOH one CI build per project per developer is probably excessive (and causes other issues). I think that live is too late because - given that we can/should have more repos (clones of) - live should be deployable whereas we want to be building/running tests (unit at commit, integration at scheduled intervals) on development commits.

I'm fishing a bit but that's because one of the things that a central subversion repo gives one (me, with our setup!) is a lot of clarity about what to build when.

n.b. I'm not asking about the mechanics of using mercurial with continuous integration - I have that working a treat for a personal project, its patterns and structures and working practice/workflow that I'm trying to get my head round.

  • Why do you think it is too late to trigger builds from the central/"live" repo?
    – c_maker
    Dec 2, 2011 at 17:08
  • If you haven't been there already, I suggest you head on over to the Kiln stack exchange site (kiln.stackexchange.com). They have quite a bit of content about how to set this up (here's one: kiln.stackexchange.com/questions/29/…. Personally, we use a branch per feature, and point the build server at our "master" branch.) Dec 2, 2011 at 17:14
  • @Chris - I have, there isn't really, not addressing the CI issue...
    – Murph
    Dec 2, 2011 at 20:50

3 Answers 3


First, having multiple builds per project in TeamCity is really the way to go. The nature of the platform makes it really easy -- the copy button is there for a reason.

In any case, when we were on SVN, we typically ran 2 builds for each project -- one pointed at the main development line (in our case the trunk) and one pointed at our release branch. We carried this build setup over to HG while following a branching model similar to this one . Only real challenge has been finding a new funk schwea about build numbers now that we could no longer use current SVN revision number.

We try and encourage folks to push relatively often, especially when there is lots of work going on at once and we wanted faster feedback cycles. Just because it is a DCVS doesn't mean you have to only push once a day or something.

  • Wyatt, to my mind push should occur when you have a completed unit of work (ish) - one of the benefits of DVCS is that we can commit, locally, code that is broken. I really really dislike the notion of doing anything on a schedule because its the end of the day. There is a separate issue of "backup", that - to me - is about setting up a rule to push sideways - on commit - to another clone that exists just to be a backup.
    – Murph
    Dec 3, 2011 at 8:59
  • 2
    Trick there is what is the definition of unit of work? Is it "this feature is complete" or is it "this brick is successfully laid". We tend towards the latter, especially with that branching model where there is a clearly deliniated development branch. Breaking stuff is best left to feature branches. Long-running ones of those can get CI builds too if possible. Especially if there are multiple cooks in the kitchen. Dec 3, 2011 at 12:40
  • I agree with your definition of "unit of work" which is why I'm struggling a bit with my overall model (which already has multiple builds per project variously to accommodate both "CI" builds and "deployment" builds). You're right, the answer is to wire up lots of builds so in the end my real issue is going to be getting the cheque signed! The branching model referenced looks about right - too. Still considering the overall pattern (and allow that that will get further adjusted to allow for specifics of kilnhg)
    – Murph
    Dec 3, 2011 at 13:22

We've been using Kiln for about a year now and have tried several different things. Where we've ended up is to used named branches (as opposed to branch clones) with the following branching strategy:

  • default tracks "completed" development
  • feature branches track work that's currently in progress
  • release branches track points where we released from default

So, work starts by creating a feature branch from the current tip of default. When the feature branch is done*, the branch is closed and merged back into default.

At some point, we decide that we're ready to release, so we create a new release branch from the current tip in default. This allows us to make changes to the code that's currently in production by committing to the release branch while still allowing active development on the feature branches and default.

As for continuous integration, we do two things:

  • An "always on" integration that monitors the status of default
  • New integrations for each release branch

The default branch job lets us know that our main source tree is always stable -- the release branch jobs let us know that those branches are stable and provide us with the build output we need to push a release into production.

*Our definition of "done" is that the feature is up-to-date with merges from default and has been approved in code review.


If you move to a DVCS, like Hg, you're not only getting the "distributed part", you're also getting the full power of good branching and merging.

Considering that now you'll have a good issue tracker and a good SCM... why not creating a branch for each task?

The "branch per task" pattern is not new (check Berczuk's book) but it is definitely something to try.

I explained it in detail here, and the pros and cons of CI vs "controlled" here.

  • I would say "better" rather than "good" since I've happily, enthusiastically and successfully done both feature and maintenance branching and merging with subversion (-:
    – Murph
    Dec 10, 2011 at 11:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.