Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

Forking will become normal in 2011, so get ready for GitHub

The growing use of distributed version-control systems can't be ignored in your enterprise; plan ahead to keep your developers happy in 2011

Feature  By Savio Rodrigues, InfoWorld, 12/23/10

Forking is often viewed as a last resort for software projects. However, the growth of GitHub and other distributed version-control systems, along with a reluctant acknowledgement from a key vendor of the popular Subversion version-control system, suggests that forking is going to become commonplace in 2011. Plan ahead to ensure your company is ready for this shift in development methodology.

Centralized version control rules the day -- today
Version-control systems (VCSes) fall into two broad categories: centralized and distributed. The merits of each have been widely debated; here is a good detailed explanation of the differences.

[ Keep up to date on the key open source developments in the Technology: Open Source newsletter. ]

A centralized VCS relies on a central server hosting the main or trusted version of a project, often referred to as the "trunk." Developers check code out and in against that central copy of the project. There is only one copy of the entire source code for the project, on the central server. Developers on a project can see a change from another developer once the first developer has checked his or her changes into the main trunk.

Distributed VCSes, on the other hand, are designed so that any repository could be considered to be the "main" or "trusted" version of the project. Each developer has the entire project's source code in a local repository on his or her computer. As such, developers on a team can share changes with each other, in each other's local repository, before merging their changes into a common, centralized repository.

The vast majority of VCSes used in public open source projects and internal enterprise software projects are centralized. An analysis of more than 240,000 open source projects tracked by Ohloh demonstrates an overwhelming bias toward centralized VCS usage such as Svn (as Apache Subversion is usually called), Svnsync, and CVS. Distributed VCS such as Git, Mercurial, and Bazaar account for just 14 percent of usage.

Data from the 2010 Eclipse User survey, which can be used as a proxy for internal enterprise software project usage patterns, reveals a similar preference for centralized VCSes. Distributed VCS usage accounts for just 11 percent of VCSes used by the 1,528 respondents to this question in the survey.

This data suggests that open source projects are ahead of the curve in adopting distributed VCSes. However, the 3 percent difference in usage between the two data sources could be well within the margin of error for each of the surveys.

Suffice to say, distributed VCSes are not commonplace in today's software development practice. But that's about to change.

Expect growing use of Git/GitHub, Mercurial, and the like in 2011
Forrester Research analyst Jeffrey Hammond tweeted, "A sign that Git has arrived," and linked to a press release from WANdisco, a key vendor behind the centralized VCS open source Subversion project. According to the press release:

"Enough is enough," said David Richards, president and CEO of WANdisco. "Subversion gets a lot of criticism due to the shortcomings of branching and merging, especially when compared with Git and others, and we simply don't have the time to debate whether or not this should be done when it clearly should be."

As a result, WANdisco will devote resources to improving Subversion's branching and merging capabilities. The press release clearly demonstrates that the growth of Git and other distributed VCSes are raising concerns for WANdisco and some of the largest users of Subversion.

GitHub, a Git-based online community for collaborative development, counts more than 508,000 users hosting 1,524,000 Git repositories as of this week. According to RedMonk analyst Stephen O'Grady's analysis of repository type mentions on Hacker News, distributed VCSes account for 86.5 percent of repositories mentioned and 82.1 percent of the total mentions are for Git alone. As O'Grady explains, "This dataset is interesting not because it is representative of developers as a whole, but rather because it's a community of technologists who are collectively ahead of the curve."

Prepare for distributed version control in your enterprise
The growth of Git, GitHub, and the forthcoming changes to Subversion give IT decision makers a reason to consider distributed VCSes in 2011.

As with any shift in the software industry, I advise decision makers to experiment with a distributed VCS on a small project to gain experience without affecting business-critical systems or projects. A small trial project could help identify internal process changes required when shifting from the current centralized VCS to a distributed VCS.

Keep in mind that distributed VCSes provide a complete copy of a project's source code on a developer's local computer. If your current development practice requires that only portions of the source code tree be available to certain developers, you'll need to use multiple repositories to represent an overall project and restrict developer access to the appropriate repositories.

Additionally, if your developers use laptops and there is a risk of the laptop being lost or stolen, consider that the entire source code to the project is now on the laptop, versus just a branch in your traditional centralized VCS.

Finally, plan for training to help developers familiar with centralized VCS approaches learn how to quickly become productive in a distributed VCS environment.

None of these cautions should be viewed as reasons to not consider using a distributed VCS in your development environment in 2011. Get ahead of the curve with a distributed VCS. If developer views on GitHub are an indication, your developers will thank you.

Follow me on Twitter at SavioRodrigues. I should state: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies, or opinions."

This article, "Forking will become normal in 2011, so get ready for GitHub," was originally published at InfoWorld.com. Read more of Savio Rodrigues' Open Sources blog and follow the latest developments in open source at InfoWorld.com.

For more enterprise computing news, visit InfoWorld. Story copyright InfoWorld Media Group, Inc.