I'm a big mercurial fan. I use it almost exclusively these days for my own work.
I've also used hg to deploy code to small lab/production sites and track any changes made and/or push those changes to other nodes in the cluster. I don't know about you, but I don't always get configs right the first time :) It seems to be more effective to version on production/lab and push changes back to development than cycle through an entire high-ceremony release process because said process is trying to risk manage everything. Let's call this model "checkout to server", which I'm happy to pretend is just like pull based manufacturing.
Anyway. While I'm sold on DVCS like hg for personal work, and even for running local developer branches alongside something like perforce or subversion, I'm less clear on how that works in "commercial" settings, or how you'd adopt mercurial in teams that have grown up on central repositories. So I was wondering if anyone out there was using mercurial (or git, or darcs, or bzr) in team scenarios and had patterns for assigning master repositories - ie faking a centralised repository*. The release management literature I know of assumes you have a central repository of some sort. The only information I've seen is from Kelly O'Hair at Sun, who did a series of articles explaining how the OpenJDK release process works with mercurial.
Any pointers?
* yes I know; the central model is clearly wrong, wrong, wrong and I've seen the Linus talk as well. Cut me some slack here :)
2 Comments
The way we do it (err, or will, once we've actually finished switch from SVN :) is just by "blessing" a certain repository as the "master."
So we enforce pushing to the master any more than we enforce checking for syntax errors before committing: it's all cultural.
Centralized deployment tools really help here, too. When we deploy code out to production servers it'll only come from the blessed master, so code not checked in there will never make it into production.
All that said, we're only switching because we have a business need to have multiple continuous branches with peer-to-peer merging. I don't see the benefit of DVCS if you've really only got one master.
Jacob:
The benefit is branching. You may not have long-running branches, but you *always* have branches. You have them even with a centralised VCS: a working copy is a non-first-class branch. Now imagine how nice it would be to have versionining *within* your working copy, and to be able to preserve that history when finally committing. Suddenly you can make local commits at every step and turn of your work, without fear of Breaking The Build, because no one else will see your changes until you decide that the bundle is safe for consumption. All sorts of social pressures created by the dependence of everyone on the same shared space just fall away.
*That* is what you gain from DVCS, more than anything else.