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.