How to setup a DVCS system that keeps some of the stuff we like about our centralized VCS?

Right now, we have a small team of developers using T开发者_如何学运维FS for our version control. I'm evaluating the possibility of us moving to a DVCS, and am wondering if we'd need to give up some of the stuff we like about our current system if we moved to DVCS, or if we can find a way to support it.

Right now we a Stable branch, and 1 branch for each developer (you can think of each dev's branch as a feature branch that is reused from feature to feature). The stuff we like is:

1) Each time a dev checks in changes to his branch, we do a build and test of everything on the servers, followed by automatic deployment of all projects to that developers test environment.

2) Merging from any dev's branch to Stable is done by me, so that I can have 1 last check on what is happening to our stable branch before committing the changes.

3) If I want to help a dev with something, I can just grab latest from their branch and look at it on my machine.

I'm trying to understand how this could work with a DVCS (specifically we are testing with Mercurial).

I'm hoping to be able to pull off something like this:

1) We setup a central repository, and we create Main and Release branches in addition to 1 branch for each developer.

2) All devs clone the repository to their local machine.

3) All work is done in their personal branch against the local repository.

4) When they are done, the would pull from the central repository, and perform a local forward integration merge from Main to to their branch, to integrate any changes that have happened in the past to Main.

5) They would then push their changes to the central repository.

6) Some CI service would pickup this change, causing a build/test/deploy-to-dev of all our projects in that branch.

7) If everything was ok the dev would shoot me an email saying their branch was ready for merging to Main.

8) I could then merge in their changes, either by somehow connecting directly to the remove repository, or by doing a pull->merge->push.

So to deal with our requests:

1) I'm assuming there is some CI tools that can watch a branch in Mercurial, and kick off a build/test/deploy process (like CC.Net).

2) I can still manage the final merge process from DevX to Main either by connecting to the remote repo, or by pulling, merging and pushing through my local repo.

3) I believe I could either pull changes directly from another dev's repo, or I could just pull from the central repo, and then update my working directory to work on their code.

So do I have this mostly right?

Yep, you have all that right. Regarding you final assumptions:

1) There's a Mercurial Source Control Block for CruiseControl.NET. Another CI server I've heard of in use with Mercurial is Jenkins.

2) Correct. For integration with Main, I would prefer pulling (from either) and merging on my own machine before pushing, rather than merging on the server.

3) Exactly so.

It sounds like your developers are fairly disciplined, but just in case you need better control certain aspects of your operations:

• You can use hooks to issue warnings when someone tries to merge their branch to Main. In-process hooks have to be written in Python, but they have access to the Mercurial API that way. You could also place hooks on the server that reject pushes containing a merge to Main not done by certain users.
• One way some organizations control integration is a pull-only scenario. Only a few developers can push to the official repository and other developers send them pull requests. The Mercurial book's Chapter 6 covers this a bit, too.

A branch per developer is good. A branch per feature is also useful, allowing each developer to work on multiple things in parallel, then merging each to their branch when done. They just have to remember to close that feature branch before doing so, so the branch name doesn't keep popping up. This can be done with with clones as well, but I find myself preferring named branches since I have to keep work/backup/laptop development clones all synced so I can work on whateve, whenever. I still do expendable work as a clone first.