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

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.

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.

1 A correction; you can write out-of-process hooks though they won't have access to the API as easily as a Python hook, but it's doable. Also, an addition, TeamCity works with Mercurial as well. – Lasse V.

Karlsen? Aug 1 at 7:11.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.