Suppose I were dealing with career software developers, backed by real money, who also happened to be intelligent, thoughtful people, and I wanted to make the case for git vs. CVS/SVN. I'd start by handing them copies of the O'Reilly Perforce book and suggesting that they read it cover to cover. Focus on the chapters on how well organized development and release branches, and good tracking of feature/fix propagation among them, can help you cope with the vagaries of real-life software development. Then I'd explain the relative merits of Perforce and git -- on one hand, availability and quality of documentation, training, tech support, and Windows versions; on the other hand, a genuinely distributed design, which means that you don't need psychic powers to arrive at a sane branch structure. Specifically, git's design makes private branches ultra-cheap for the developers that use them and zero-impact on the release infrastructure, and the integrity of _content_ and _history_ doesn't rely on any resemblance between my branch layout and yours. Speed, scalability, zero license cost, and the hypothetical ability to hack on it yourself are nice too, but they're basically fringe issues unless you're so big that you can't just throw money at the problem -- in which case they're still fringe issues because you're the enterprise-customer tail that wags the vendor dog. (If you're big _and_ cash-poor, or if you're stuck on a VC system so badly designed that no amount of money thrown at the problem will help, you have a different problem.) If you do this right, it should be clear that CVS is in the dust on all fronts and SVN doesn't (AFAICT) have any advantage over Perforce that git doesn't have more of. You might also mention that git was designed by Linus to systematically not suck, and has been successfully handed over to a strong maintenance/enhancement team that works in public view. And Linus is still here policing to keep suckage from creeping in. ;-) The hypothetical smart developers will then agree to go with either Perforce or git, depending on which the people who have to do the hard work -- release managers and the IT Morlocks -- are most comfortable with. If you take this route, be prepared to wind up with Perforce. It's got its weaknesses, and I prefer git myself, but you could certainly do a lot worse. I'm not as anti-SVN as Linus, but there aren't many workflows for which I would recommend it over Perforce. Personally, I wouldn't voluntarily introduce any other version control system into the discussion, because the others that I've used in the course of one day job or another suck massively by comparison, and the ones I haven't used (or have only toyed with) don't appear to have any compelling advantage over git. (Having _marginally_ better documentation isn't much to brag about). Until someone writes a good book on git and sets up shop as a commercial support organization, presenting Perforce vs. git as a classic buy/build decision is probably the best you can do. (You don't have to "build" git, of course, but you'd have to build your own in-house training and tech support capability.) I say this as someone who routinely sits in the "release manager" chair, uses git by choice, and is currently suffering the pain and agony of migrating a perfectly good git-based integration process to Perforce, simply because it appears to be the right thing for this developer organization. (Doubtless this colors my opinion du jour.) Cheers, - Michael - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html