Sussman on DVCS, Van Zyl using GIT+SVN

by Tim O'Brien

Ben Collins-Sussman has an interesting blog entry about Distributed Version Control titled "Version Control and “the 80%”. Here's an excerpt:

...In a nutshell: with a centralized system, people are forced to collaborate and review each other’s work; in a decentralized system, the default behavior is for each developer to privately fork the project. They have to put in some extra effort to share code and organize themselves into some sort of collaborative structure. Yes, I’m aware that a DVCS is able to emulate a centralized system; but defaults matter. The default action is to fork, not to collaborate! This encourages people to crawl into caves and write huge new features, then “dump” these code-bombs on their peers, at which point the code is unreviewable. Yes, best practices are possible with DVCS, but they’re not encouraged. It makes me nervous about the future of open source development. (Maybe the great liberation is worth it; time will tell.)

I don't see decentralized version control working for a smaller set of projects like Jakarta Commons. For smaller projects, I don't think the overhead of a DVCS is worth the effort, but for larger projects like Wicket or Maven, I think DVCS would encourage more external contribution. I also don't think that forking is the opposite of collaborating - forks are part of the creative (read messy) process of evolving a code base. I can think of a few situations where a fork would have been helpful in the past few years (Struts during the Shale debacle and I'm convinced that someone needs to fork Maven documentation into an external project). An ideal fork competes with the original and inspires change.

...and, if you don't believe me...

Jason Van Zyl wrote the following email to the Maven developer's list on September 29th:

...for anyone who has patches or wants to try and work with me to
get changes in I am going to try this method of publishing Maven as a
GIT repository which will allow anyone to clone the repository and
work on any changes you like in a controlled way. Once you clone you
can commit changes to your own copy of Maven and do whatever you
like. Then in order for me to see your changes I can simply pull from
your originally cloned repository to a branch on my side and merge.
Merging is sooooooo easy with GIT. So easy in fact that it makes you
wonder how SVN got it so wrong and makes it so painful compared to GIT.

He continues later in his post:

In the short term I really only want to try with a few people but if
you're keen, want to learn about GIT (which I highly, highly
recommend) then I will take your patches. I think any developer here
and anyone who has ever tried to contribute changes sees that the JIRA
+patch model is highly unworkable and bordering on completely
useless. JIRA might be fine to raise the issue but with a reference
to a GIT repository to pull from it will make life infinitely easier.
People who are not committers can work with people that are in a way
that resembles everyon being part of the team. Dealing with patches
just sucks ass and as a result we don't look at them nearly as often
as we should so I hope this can become a model that enables people to
contribute in a more effective way. I'm going to try this with Oleg
but I am highly hopeful. I will help anyone who wants to try this as
I see this as a way to truly collaborate with the community. Down
with JIRA+patches! All hail JIRA+GIT! :-)

Oh, and about Sussman's 80%. I think we can replace them with some Ruby scripts.


Mirko Friedenhagen
2007-11-09 15:52:41
Is there a reason why you choose git for this? This excludes people running Windows. I use Mercurial after having used git for about 2 months, which is cross-OS and has a much better command line help then git IMO. The procedures are very similar with git and Mercurial.