I too am looking for talent and capital.

Best wishes! This is the future.

The reason why I avoid git is similar to the reason I avoid bzr. In the case of bzr I’m scared because it’s Canonical’s baby. If Canonical decides that their baby should have seven heads then it will have seven heads.

In the case of git, my concern is not with a corporate entity but rather with the fact that it’s heavily tied to the Linux kernel development team. I’m not sure how well supported it is on *BSD or Solaris, for example (and I do care about such things). It could be that it works really well on these platforms and that there are really active git maintainers in the communities. I don’t know, and right now I’m happy with mercurial so I have very little reason to investigate.

I don’t know if Linus’ comments about Subversion developers are fair, but I get annoyed by Subversion users, who assume Subversion is the One True revision control system. I don’t criticize anybody for using Subversion. Funny enough, I constantly find that I have to defend myself for *not* using Subversion. Reminds me a bit of a certain religion (no points for guessing which one), or Gnome users and developers.

Yes, it’s fast and efficient, and I’m sure that if I stayed within a very narrow band of expected usage it would have been reliable for me. But the truth is that I could never see asking my co-workers to switch to such an arcane and finicky system. SVK is vastly simpler in comparison (if all you need is a DVCS wrapper around Subversion, like me), with it’s 4 basic commands.

Compare that to the 20+ commands I kept having to use to fight with git — just to keep it usable, damn it! — and the answer becomes clear.

I agree that distributed VC is better than centralized, but your rag on CVS/svn is too much. When it was new, CVS was as world-shaking as git & co. are now, and you couldn’t have distributed VC without CVS’s innovations. Today, using CVS makes no sense; six or seven years ago, though, it was the market leader, and deservedly so.

As an aside, check this out:

http://www.chipx86.com/blog/?p=222

It’s a code review system for Perforce and Subversion that even the git people could probably benefit from. Is it any surprise that one of its promised benefits comes from bridging centralized repositories, even of different types?

Recently, I’ve created a workflow around mercurial. I use tailor to automatically sync p4 changes from everyone else into an online mercurial repository, and I’ve got a simple tool on top of mercurial queues that pushes my changes back to perforce.

Yesterday, I was working from home and created somewhere around six changesets for new features (and a little code cleanup, etc…). My connectivity went down while I was in the middle of all this work. I didn’t notice.

Centralized revision control makes no sense in any context. Conceptually, there’s nothing you can do with centralized revision control that you can’t do with decentralized tools, but the converse is most definitely not true.

I’ve personally not used git (partially because it’s less interesting than mercurial, and partially because my package system won’t actually give me a build). I have used rcs, cvs, svn, perforce, gnu-arch, darcs, and mercurial extensively. Ten years ago I had people argue with me about how much better rcs on shared filesystems was than cvs for developer productivity. Ten years from now, centralized vs. decentralized will sound equally absurd.