David Rubinstein of SD Times recently published an article on branching and merging titled “Branching and Merging: the heart of version control” at http://www.sdtimes.com/content/article.aspx?ArticleID=36328&page=1
In this article, David discusses the rise of distributed version control systems (DVCS) within the software development community at large. While I cannot disagree that DVCS systems are gaining in popularity, I personally have not yet seen them dig deep roots into the enterprise space yet. I think there are multiple reasons for that, some perhaps that will never be overcome.
First, take the CTO/CIO perspective. Your responsibility is the software systems of your company, and the source code of those systems is the most critical asset. Are you going to store that critical asset in a system where there is no master centralized version? Would you run an accounting system where there are many, many copies of the General Ledger? (Well, maybe you do if you are doing something illegal!) Especially those software systems that run financial transactions, or that may have compliance requirements, a DVCS solution for source code control is going to face a tough battle to get adopted because there is no central source.
From a configuration and release management perspective, there is a firm need to understand what code shipped when. Companies need to be able to answer the question “what code did you ship to production” in a definitive and accurate way. DVCSs need to be configured and governed such that that question can be answered, especially when the auditors come around asking questions. The DVCS tools available today do not provide much help in answering this question, as they do not enforce a strict promotion model, and rely on the people using it to enforce that model.
From a developer perspective, I more often than not see enterprise developers struggle with merging. Even simple merging, in my experience, is seen as a major overhead and a scary thing that can break code bases badly. You simply cannot use a DVCSs without having a firm grasp on merging. If developers are struggling with straightforward merging of with a centralized version control system (CVCS), it is not going to get any better for them with a DVCS.
As noted in David’s article regarding CVCS tools, there are several complaints that I’d like to address.
• Broken builds: With everyone ultimately working in the main line, code reconciliation on large projects is extremely difficult.
If code reconciliation is a concern, then this must be a bigger or at least the same concern with DVCSs, right? With large, active projects, this is just the way of life, and a tool cannot solve it, centralized or distributed. If you have a lot of code to merge, then you have a lot of code to merge. Period.
• Branching limitations: This prevents parallel and agile development from taking place.
Maybe this is just my experience, but I have not seen any modern CVCS tools that prevent parallel or agile development from taking place because of branching limitations. When you need to create a branch, you create it, use it, and merge back regularly. Once the branch isn’t needed anymore, get rid of it. Have a plan for creating branches and stick with it.
• Arcane branching patterns: Users are locked in to their tool of choice.
Again, I’m not aware of any good CVCS tools that strictly enforce “arcane” branching patterns. You define the branching pattern that you put into place in a CVCS tool. I’m also not sure what is meant by “locked into their tool of choice”. Doesn’t every version control system lock you into it?
• Not distributed: Makes remote development difficult in terms of access to code.
Generally, yes, but CVCS vendors are addressing this. If you have a centralized repository sitting in Atlanta, and have developers from India working on it, access could be slow. Then again, the DVCS answer is to replicate the entire repository locally, making access fast, but you would think at some point you’d want to push code back to Atlanta?
A great example here is the upcoming release of Microsoft Team Foundation Server 2011 (TFS). In these blog posts, Brian Harry of Microsoft talks about merging enhancements and offline workspaces that bring DVCS-like functionality to Microsoft’s CVCS product.
• No flexible release cycle: Does not enable continuous integration and agile deployment of code.
I definitely have not seen this before. At AgileThought, we are using a CVCS (TFS), and do extensive continuous integration, and agile deployment of code, through a structured promotion model. I actually see this as a disadvantage for DVCS’s – since there is no central repository, where do you do continuous integration? The answer I’ve seen often is to do define a single “blessed repository”, have someone sit in the role of “integration manager”, and routinely push to that repository so a continuous integration build can be run. All in all, a very manual process, but CVCS tools support this concept very well.
As pointed out in Mr. Rubinstein’s article, distributed systems have their drawbacks as well. Git has an steep learning curve, and right now requires knowledge of a command line. While “command prompt only” should never be a blocker for professional software developers, in my experience, it can stall adoption if developers are forced up a steep learning curve. Also, the lack of a central source repository may not sit well with those responsible for the safekeeping of their companies source code.
DVCS systems are extraordinarily powerful, and CVCS vendors have sat up and taken notice. DVCS will likely always remain the de-facto standard for hugely distributed, contributory projects (such as open source projects). However, I don’t believe that in the enterprise space, that a pure DVCS solution will be the future, but rather, a hybrid of CVCS with DVCS-like features. Tools like Git will continue to innovate DVCS features, and CVCS vendors will likely adopt the best features to address the needs of enterprises.