Michael Foord writes:
If I can't choose a clear winner I am going to look into what it take to run directly on top of svn to avoid the extra step for committers.
Well, that sounds like an ideal situation to end up in. Is there a downside other than the work it creates for you?
I'm with Brett, the extra work for him is more than downside enough. But over and above that, the various DVCSes have different strengths and weaknesses, and their proponents have different mental models of how DVCS is "supposed" to work. I believe this is reflected to a great extent in their capabilities, creating great friction to trying to work with a different VCS from the "native" one of the master repositories. You just end up using a buttload of extra CPU cycles to achieve a Subversion-based workflow. The big advantage, IMO, to going to a DVCS for the master repo is that you can start with the same workflow currently used, and gradually adapt it to the capabilities of the more powerful tools. If we don't do that, the workflow will never really change, and the project-wide advantages of the tools will be lost.