LOGIN | REGISTER NOW | SUBSCRIBE
 
Print

Branching and merging: the heart of version control


By David Rubinstein


 David Rubinstein
Email
February 1, 2012 —  (Page 1 of 3)
_
Git.

The open-source distributed version-control system has attained such a level of popularity in such a small time that the larger, centralized enterprise SCM software providers have had to sit up and take notice.

And they’ve noticed two key things. First, Git users sacrifice quite a bit of functionality around security, workflow and tracking that the centralized, commercial SCM systems offer. And second, many engineers don’t care. They want to work in Git for its low barrier to entry and its branching and merging capability. So, several enterprise SCM providers are coming out with Git-supported versions of their software.

There’s one other thing many in the SCM world acknowledge, as summed up by Alex Malinovich of GitHub: “It’s clear that traditional centralized SCM will be extinct in the not-too-distant future.”

Scott Farquhar, cofounder of tools provider Atlassian, which owns the Bitbucket code hosting service, echoed Malinovich’s remarks: “The way we develop has changed, with shorter timelines, the number and departments of people involved. I can’t see anyone starting a new project today and not using Git or (other DVCS systems) Mercurial or Bazaar.”

Bitbucket product manager Justen Stepka added, “In large organizations, where it’s disruptive to the bottom line to switch (SCM systems), I think you’ll see new projects begin on Git, and over time, the number of projects on Git will surpass the number on Subversion or Perforce.”

These developments are even more remarkable when you consider that source-code management had been unchanged for years. Developers wrote code, checked it in to a repository, checked it out to fix bugs or add features, and reconciled it with the main codebase to make sure nothing was broken by the revisions. Everyone understood. Branching was strictly forbidden, because manual reconciliation, and the repair of broken builds, made the practice too risky.

Then, around 2000, DVCS came along, and more specifically Git, which came out in 2004 and began to get some traction by 2007. But Eric Sink of SourceGear, author of the book “Version Control by Example,” said the credit for popularity goes not to Git but to GitHub, the hosting site that launched in 2008.

“It has become a social network for open-source developers,” he said. “It has become a sort of Facebook. They’ve found a sense of community, found a place they belong. That’s a big factor as to the popularity of Git.”

“When you get down to it, guys who like Git work in loose groups and want a low-overhead way of merging,” said Jim Duggan, analyst at Gartner Research.

Make no mistake, the DVCS and centralized sides are forming against one another. “Corporate developers are hearing at the pub from their buddies that Git is great,” said Mike Pilato, a software engineer at CollabNet, which contributes to the Apache Subversion SCM project. “It makes for battles inside enterprises. But we don’t want to move to DVCS. If we do, we admit it’s the only way to go.”

Sink cautioned, “I think we have to be careful about getting a black-and-white mentality about it. Millions of happy Subversion users would take exception with the statement that anything not distributed is obsolete.” Distributed may be the way, he said, “but you’ll see a number of different players with tradeoffs.”

Francisco Monteverde, CEO of Plastic SCM company Codice, pointed out what he believes are the problems of yesterday’s SCM systems:
• Broken builds: With everyone ultimately working in the main line, code reconciliation on large projects is extremely difficult.
• Branching limitations: This prevents parallel and agile development from taking place.
• Arcane branching patterns: Users are locked in to their tool of choice.
• Not distributed: Makes remote development difficult in terms of access to code.
• No flexible release cycle: Does not enable continuous integration and agile deployment of code.

Distributed systems have their drawbacks as well, according to Perforce’s Randy DeFauw and others:
• Git has a steep learning curve.
• There is no effective GUI yet, so it appeals more to power users than enterprise developers.
• It requires a full copy of a repository to be uploaded outside the firewall to multiple disparate developers, has issues around security, and access has become more critical (although submodules are either here or on the way in several DVCS systems).
• The system is only designed to work with text-based files, such as source code.
• There is no “master” file or canonical source.


Related Search Term(s): Git, SCM

Pages 1 2 3 


Share this link: http://sdt.bz/36328
 
Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter



Comments


02/02/2012 10:12:59 AM EST

It's a shame that Mr. Rubenstein feels he must twist words and context to create the illusion of controversy, leaving those he purports to quote to clean up the mess. Please allow me to clarify the statement attributed to me, which in its original form would have been about Subversion's destiny (and nothing more). The Subversion developers have no plans to transform it into a DVCS tool. The market still needs centralized VC, and Subversion is the best offering in that space. And if, some day, DVCS emerges as The Only Way To Do It, then there would still be no need for Subversion to adopt that model because several great DVCS tools already exist.

United StatesC. Michael Pilato


02/06/2012 03:14:16 PM EST

At my company, we use subversion to do all our centralized version control, but I have started using Mercurial to interact with it. Mercurial supports a plug-in called hgsubversion that allows me to clone a subversion repository into a local mercurial repository. I then make all my commits locally. When I feel the need to share those commits with the others on the team, I then "push" my local commits to the subversion repository. And when I need to get other's changes I can "pull" them from subversion repository into my local mercurial repository. I have the best of what both DVCS and CVCS have to offer!

United StatesJack C. Holt


02/06/2012 03:38:03 PM EST

Front-end closed-source web apps are reverse-engineerable anyway. Enterprise dev may as well use Git and enjoy the DVCS benefits, like open-source, accept pull reqs. But how do teams inexpensively manage the server-side "security-inside" 'secrete-source' code?

United Statesclive boulton


02/06/2012 11:58:01 PM EST

This is a pretty revisionist history. Branching forbidden before 2000? I wonder what I was doing in ClearCase for all those years?

AustraliaMark McLaughlin


03/21/2012 12:42:44 PM EST

I disagree with the overall theme of the article that client-server (aka 'yesterday's SCM systems') cannot support agile/parallel development, which is absolutely wrong. I've implemented clearcase branching schemes to support both parallel and agile, and I've seen others do the same. Broken builds? That's the world of waterfall, and again, you assume everyone works on the main branch, which is not necessarily true if you design your branching schemes correctly. Arcane branching patterns? Only if it make it arcane. remote development? Not true, replicas, remote logins, web-based access all facilitate remote development. No flexible release cycle? Wrong again. Many companies are using CI and agile using 'yesterday's SCM systems". It sounds like yesterday's tools can't do agile period, and only DVCT's can, which is wrong.

United StatesMarc Towersap


03/22/2012 01:17:01 PM EST

I agree with most of the previous commenters. The author seems to equate fast/flexible branching & merging capabilities with decentralized version-control systems (DVCSes). This of course is not the case at all, and many thousands of organizations and tens of thousands users were doing it in the 90s with commercial tools. There just werent any popular open-source tools that did it as well until Subversion (and later Git) entered the the scene. (oh -- and lets not forget Bitkeeper and Arch, which were the original DVCSes long before Git). Both SVN and Git (and many other open-sources and commercial tools) these days support fast and flexible branching and merging. That issue is very different from the centralized vs decntralized issue. That often has to do more with security and control (which definitely causes friction against the flow of development.) The author is correct that vendors are sitting up and taking notice about Git and other DVCSes. They are noticing that even in large organizations the trend is to be more collaborative and less command-and-control, so they are either implementing some DVCS capabilities (like Perforce's P4Copy) into their systems, and/or implementing capabilities that allow treating an SVN sandbox or Git repo as a "local client" that it can accept changes from as per configured policies. The industry-wider trend at this point is not strictly toward DVCS instead of CVCS, it is to be able to use them *together* so that some centralized control and policies can be more easily setup and secure at the enterprise level (and in the cloud) while still allowing distributed peer-to-peer collaboration from distributed "agents" (be it a "client" or a DVCS rep) to higher-levels of integration across a larger product or system with multiple independently collaborating partners.

United StatesBrad Appleton


close
NEXT ARTICLE
Zeichick’s Take: The 8-year-old Git is coming on strong
A CollabNet survey shows that Git is making impressive ground in the enterprise Read More...
 
 
 




News on Monday  more>>
Android Developer News  more>>
SharePoint Tech Report  more>>
Big Data TechReport  more>>

   
 
 

 


Download Current Issue
MAY 2013 PDF ISSUE

Need Back Issues?
DOWNLOAD HERE

Want to subscribe?


 
 
 
 

Events calendar tab
CTIA 2013
5/21/2013 to 5/23/2013
Las Vegas
CTIA

AnDevCon Boston
5/28/2013 to 5/31/2013
Boston
BZ Media LLC

Fluent Conf.
5/28/2013 to 5/30/2013
San Francisco
O'Reilly Media

Better Software Conf.
6/2/2013 to 6/7/2013
Las Vegas
SQE

IBM Innovate
6/2/2013 to 6/6/2013
Orlando
IBM Rational