Distributed Version Control Systems (DVCS) have been gaining popularity in the recent years. Here’s Linux creator Linus Torvalds talking about Git and why developers should consider moving to DVCS from traditional centralized repositories.

Personal thoughts below the cut.

As a developer who has used centralized VCSs for the past 4 years, having the repository hosted in your own computer is the most appealing feature about DVCSs.

The problem with relying a centralized server is that, in a team, the collaborative aspect of revision control has priority over version tracking. That is, developers are discouraged to commit their work in progress because of the fear that they may break the build, but this prevents developers from tracking down their progress while coding. In extreme cases, say, when a developer is working on a very complex module, not being able to commit anytime they want is practically the same as not having a VCS in place at all.

DVCS does not have this problem. Developers can commit anytime they want without the fear of breaking the build because no one else is using their repository. It’s only when they are ready to push their changes to the designated central repository that they need to be wary of breaking the build.

I think the most interesting part about DVCSs is that while it can be used like centralized VCSs where developers can commit/push to centralized servers, they are designed for the “pull” approach:

DVCS pull approach

Now while this is perfect for open-source development, this also holds promise for large scale projects. With multiple levels of repositories, source code can easily be controlled. I’m thinking along the lines of:

Submodule Developer —pull/push—> Submodule Lead Developer —pull—> QA Build —pull—> Production Build

with each level being able to pull changes from the top level of the chain anytime.

So will DVCSs supplant VCSs anytime soon?

The answer is no, at least, in many software houses. Migrating between version control systems are often perceived to be risky by managements regardless of the risks of sticking with their current system (which explains why people are still using VSS). The distributed approach is also not applicable in some environments and even Linus himself admits this in the talk.

The learning curve is a bit steep too. Without the video above, I might not have understood why DVCS’s commit/update approach is weird.

Share →

2 Responses to Distributed Revision Control

  1. […] How to avoid breaking builds Sep 2 Brain Dumps, Software Engineering The guy I’m mentoring right now in one of my freelancing gigs is fairly new to software development so I decided to give him a couple of guidelines (conveniently posted on the project’s wiki) on how to properly use git. […]

  2. […] him a couple of guidelines (conveniently posted on the project’s wiki) on how to properly use git. Hopefully this should spare me the horrible flashbacks to the days when everyone I was working […]

Leave a Reply