Uli's Web Site
[ Zathras.de - Uli's Web Site ]
Other Sites: Stories
Abi 2000
Stargate: Resurgence
Lost? Site Map!
     home | blog | moose | programming | articles >> blog

 Blog Topics

15 Most Recent [RSS]

 Less work through Xcode and shell scripts
2011-12-16 @600
 iTunesCantComplain released
2011-10-28 @954
 Dennis Ritchie deceased
2011-10-13 @359
 Thank you, Steve.
2011-10-06 @374
 Cocoa Text System everywhere...
2011-03-27 @788
 Blog migration
2011-01-29 @520
 All you need to know about the Mac keyboard
2010-08-09 @488
 Review: Sherlock
2010-07-31 @978
 Playing with Objective C on Debian
2010-05-08 @456
 Fruit vs. Obst
2010-05-08 @439
 Mixed-language ambiguity
2010-04-15 @994
 Uli's 12:07 AM Law
2010-04-12 @881
 Uli's 1:24 AM Law
2010-04-12 @874
 Uli's 6:28 AM Law
2010-04-12 @869
 Uli's 3:57 PM Law
2010-04-12 @867


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!
Comment on this article:
E-Mail: (not shown, hashed for Gravatar)
Web Site URL: (optional)
Comment: (plain text only)
Please Enter the following word:
Or E-Mail Uli privately.

Created: 2008-06-27 @879 Last change: 2014-04-21 @681 | Home | Admin | Edit
© Copyright 2003-2014 by M. Uli Kusterer, all rights reserved.