FOSSLC is a non-profit organization that specializes in technology and know-how to record conferences with excellent quality. Click on the icons below to view great videos from communities we are actively involved with:

 

git vs. svn will hurt clearcase and perforce

04 Apr in Git, Programming, svn, Code repositories
Git

Natural selection involves organisms best adapted to their environment passing on their characteristics to subsequent generations and out-thriving other organisms. There is a fierce war going on between open source code repository tools. Who will win? I believe the only certain conclusion is that open source will win at the expense of closed source. Let me explain why.

In the business world, Porter's 5 forces model helps explain what we're seeing with code repositories. 

Porter's 5 forces model

The arrival of new entrants Git, Mercurial, Bazaar, and more has provided more options. The switching costs between tools - especially open source tools, are decreasing with decent migration capabilities available. The net result is increased bargaining power for customers and the ability to choose the tool that best fits their needs.This is all good. Customers/ code repository users can choose the best tool for their needs.

With more strong players actively innovating and competing, rivalry in the industry competition becomes more intense. This intensity will drive more innovation and fuel a cyclical increase in competition. The strong competition between git, svn, mercurial, bazaar and others will likely open a gap between them and closed source tools.

Japanese car manufacturers are an example to look to how intense rivalry locally can help one compete in a larger space. In this case, the aggressive competition between Subversion, Git, Mercurial, Bazzaar and others will distance themselves from closed source tools such as ClearCase, Perforce, Synergy, and others. A big part of this is an example of open source at work. Costs, risks, and benefits developing the tools are shared across a large and vibrant ecosystem rather than a single company.

Shouldering costs alone may be fine when the firm is making tremendous money. In the past, conservative corporate clients may have shied away from open source. This is less the case today. So long as there are credible support options, the features/functionality/ROI calculations will show the open source tools as an obvious front runner. Decent migration tools need to exist to make switching costs from closed source tools manageable. Corporate clients will use open source as bargaining leverage or migrate away from closed source code repositories all together.

Good money can be made here. Firms still need service and support regardless of whether the software is open or closed. However the premium charges that closed source vendors enjoyed will likely erode and force them to adapt and decide whether to continue investing. Firms that can leverage the open core model and benefit from the power of a massive open source community and yet still offer unique business value beyond will out-compete the firms based on pure open source and pure closed source.

It is always interesting to examine trend data. A recent blob post by PJ Hyett called Committing like Crazy indicates that not only has GitHub established itself, it is also likely the leading hosted code repository solution in terms of traffic. I would be very interested to compare these numbers against those of Perforce, ClearCase, and Visual SourceSafe. I've worked in large corporations long enough to know they'll hold their own, and might very well be larger still today. However in the long term, it will provide difficult for them to compete. In the long term, seemingly rigid corporate mandates to standardize on one vendors software can bend and break. As IT and Engineering teams are pushed to do more for less, open source is often a prominent consideration - this was how Linux got into the enterprise for file, print, email, and web servers.

While Git is the cool kid on the block, Subversion has not been standing still by any means. This is evident in the recently posted Vision for Subversion. In this article, Michael Pilato notes: "Subversion has no future as a DVCS tool". This is based on the community's acknowledgement that Git and Mercurial have established themselves as strong Distributed code repository tools. To try and adapt Subversion (using a centralized model) to become something it isn't would likely end up somewhere in the middle and fail. Thus I personally feel this is the right call - be true to yourself. Pilato's post rightly notes the rich heritage and value Subversion brings to the scenarios it was designed to solve - the centralized code repository.

So which code repository will win total world domination? Frankly I doubt any of them will. However it is going to be very tough for the closed source code repositories to compete and I predict after 10 to 15 years they will be very hard to find.

Comments

seems more like distributed (open) vs. centralized?

i.e. 'git' vs. 'perforce."   I'm a professional code monkey working in a code design space with a ridiculously large number of active developers.  We're easily past 500 people turning cranks on our code, daily.  For any specific "module" we're well below one hundred but the whole base acts like that... as a whole.  We've used Perforce as our RCS of choice for as long as I've been with the company.  As most readers of this article probably realize Perforce is a centralized RCS.  There's one server... it knows "the truth."  Recently I started an "off the books" sort of project.  It occurred to me that I should consider what the outside world is using for RCS.  Git is an interesting concept.  Dutifully I've picked up an O'Reilly text on the subject and while I don't consider myself an expert on git I do feel like I "get it."  This probably isn't much of a shocker: to me the primary difference between Perforce and git are the underlying problem space assumptions.  Perforce seems designed around tracking and control of a large number of diffs.  Git seems suited to situations where central control is impossible.  From those assumptions/constraints the primary flow problem that arises for me is this...    Given a pair of branches which have many edits between the branch point until the intended rejoin/merge scenario... how can we evaluate which changes have been applied already to the target branch?  In distributed systems, ala git, it seems you must build on top of the RCS to help track this problem.  With centralized RCS the "answer" to this question can be more easily understood/tracked.  I wonder: is there some reason this problem "goes away" for distributed RCS... perhaps due to built-in assumptions that apply only for distributed code development?  Or is it really still an issue?  Maybe I'm missing something entirely?  One of the first sentences in this blog article is: "There is a fierce war going on between open source code repository tools."  Is it really open source vs. proprietary/closed source or more the case that it's "distributed" vs. "centralized."    Sorry for any perceived rambling.  I'm genuinely curious... and I'm most certainly not looking to derail the thread here :)

I believe git can do the branch compare easily

Caveat: I am quite new to git myself, and thus still learning the underlying technology. It can do what you describe, and very quickly. For example if there are X updates in branchA but not in branchB, and Y updates in branchB but not in branchA. Someone will correct me if I've got this wrong or if there's a faster & better way.

e.g.
git log branchA...branchB - shows what's in branchB but not branchA
git log branchB...branchA - shows what's in brnachA but not branchB

Subversion *is* standing still

Subversion is busy whistling in the dark with papers like the one you mention, but there is very little to be seen actually coming out of it. The substandard merge tracking is now open for years, and will continue to be so for quite some time. This is because it is mostly trying to reimplement itself (WC-NG, FS-NG), and it more probable that some of the DVCS crowd will grow an SVN interface, so you can access a git repository with svn tools, to quell the main objection to git usage that I encounter. Indeed github already allows readonly svn access (unless I'm an april fool).[Andreas Krey, andreas-krey.blogspot.com]

Not sure - time will tell

The development stats for svn would disagree. There's plenty of work being done. The question you are raising is whether it is work in the right direction or not. Time will tell. I'm not willing to count svn as dead just yet myself.

Git destroys svn

All you have to do is use Git and it's clear it is newer technology and far more advanced than svn. svn blows. git rules. Next!

Love the branching, merging in git better but...

I wouldn't go so far as to say svn blows. It's a very easy to use and intuitive code repository.