The Dangers of DVCSes

Florian mentioned that Ben Collins-Sussman, of Subversion fame, did a posting on distributed version control: The Risks of Distributed Version Control. He makes some very good points.

I think, particularly for projects that work in large groups, the practice of dropping a bomb should not be encouraged. I've worked on a few projects with a developer who used to work like that, and it is very disruptive to the workflow if one developer works away in secret and the commits huge changes at once. Something always breaks...

Ben is completely right: There needs to be communication, discussion on how things will be implemented. I don't think he's aware, though, that a private branch is exactly what a distributed repository can be: After discussing the implementation with people on the project mailing list, I can create my own repository, make it publicly accessible, and start working. No need to have the maintainers of the main project create a branch or otherwise bother them.

I need a checkout anyway. I just stuff it in my Drop Box, save it in a folder that syncs to my web space or whatever, and that's it, it's accessible to the world. Even better, when I am finally ready to commit, I don't need to bother creating and collecting patches or anything annoying like that. I can just use the built-in merge facilities, and the entire history and commit log I wrote come in along with it.

It gets even easier if you're a single developer, or a developer that travels a lot. In those cases, you don't need the communication, and the freedom you get with a DVCS is great. You can sync all your Macs, work off-line on the plane, have several backups, quickly branch, more easily merge branches back, even partially, and of course you get the usual history, unlimited undo and ability to patch older versions that make version control so useful for the single developer.

So, don't drop bombs on projects, but use DVCSes all you like, they're great.

Update: Hmm... looks like I read this article ages ago, at least according to this posting: Why Distributed Version Control by Wincent.

There's also Version control and "the 80%" by Ben Collins-Sussman again, which elaborates on his thoughts, and I'm inclined to agree with him: Never undererstimate laziness. Design your defaults so the recommended thing happens. Also, the plans for SVN 2.x (and some of the improvements coming in 1.5) sound very promising, and might make SVN "distributed enough" for most users. The only thing missing is a way to set up a repository without having to mess with installing server software or anything like that, to reduce the hurdle for beginners.

Time will tell, but at the least, SVN kicked off version control development again, and the DVCSes kicked SVN in return. That's why competition can be so great: It encourages development and progress.

Reader Comments: (RSS Feed)

Dan writes: It seems like he's scolding users for not fitting their personal styles to his idea of source control. If I contribute to a project, I want to test my code somewhat so that 90% of the response isn't bug reports and negativity. That means I'm going to be refactoring. And that means I'm going to add new features. Now when I drop the bomb, I can look forward to thank you's instead of what the hell's. And what's wrong with that? After all, an open source project will never happen if you expect everyone to be doing it exactly like you want. You have to let them contribute at their own pace, it isn't a job!

Or E-Mail Uli privately.