Git Versus Subversion: A Reconsideration

Back in January, I wrote about my feelings that Subversion still beats Git when it comes to the corporate environment. I pointed out that Git has some great features, but that the corporate world was heavily invested in Subversion, and was likely to stay that way.

I subsequently got flamed.

Two months later, after using Git to contribute to several projects, I believe a reconsideration is in order. In terms of comparing Git to Subversion, Git is a superior technology for development. Git’s strengths lie in the fact that it’s been intentionally designed for things like branching and tagging; with Subversion, tags and branches are components of the file system rather than baked into the system. Git also focuses on snapshots of the repository at given times, rather than change sets. This difference in model makes Git faster, the repository smaller, and the merging of changes easier. In fact, unless there are explicit conflicts it’s unlikely that Git will experience any problems merging at all.

The distributed nature of Git makes it easy for project leaders to solicit contributions. Github in particular makes this process seamless: contributors can clone the repository, make their changes independent the main source control line, and then request that the owners of the project pull in their changes. Rather than having a few people that can take patches and turn them into commits, anyone becomes a possible contributor. The branches and work completed by the contributor doesn’t muddy the project history until it’s time to incorporate those changes, and the project owners need not grant write access to the central repository to anyone other than themselves.

So have I changed my mind about whether or not Git will beat out Subversion in the corporate world? At the moment, no. Despite Git’s great advances, and superior technology, Subversion is still the preference for many organizations. They’ve invested time, energy, and effort into setting up repositories, learning how to control access, integrating their issue trackers with revision numbers, and creating policies and procedures. Simply put, I don’t think that Git has enough of a benefit to override the internal momentum in favor of Subversion. Yet, anyway.

As new projects develop, I believe we’ll see more and more of a movement towards Git and distributed source control systems like it. For all the push right now towards Git, it’s easy to forget that Subversion as a versioning system still functions. It’s not a dead project, and it’s getting better (e.g. you haven’t needed to specify revision numbers during merging since 1.5). With tools like git+svn, developers will find their own solutions to using their favorite version control systems, and since the beauty of Git is in how it advances our own workflows, it’s irrelevant, really, where the data is ultimately stored. As more developers begin to use and learn Git (or other distributed systems), the momentum will begin to shift, as those developers become the leadership in various companies and projects, and push for the use of tools that they prefer, and the workflow they find easiest to use.

Technology will continue to mature. Who ultimately wins out and who falls by the wayside still has yet to be determined. But whoever the victor is, the important thing is that it make working easy and versioning painless – something we can all agree on that we need.

Brandon Savage is the author of Mastering Object Oriented PHP and Practical Design Patterns in PHP

Travis Swicegood (@tswicegood) wrote at 4/9/2010 8:21 am:

Nice post, but I tend to disagree on SVN working. It does for smaller instances, but I’ve seen it break down in too many companies where they have lots of people working on lots of different parts of the code with some overlap. Especially if you’re on a start-up schedule where 3 or 4 releases are being worked on simultaneously.

Git destroys SVN in those cases, hands down. SVN works, but only for relatively simple VCS (i.e., it’s just tracking the different directories you already have).

gggeek (@gggeek) wrote at 4/9/2010 10:11 am:

@travis: if you read the thread on lwn.net that followed the announcement of the svn roadmap, you’ll find that ‘big repo’ is primarily one of the use cases where svn still has big advantages over git – namely that with svn you can download only a small fraction of a repository, while with git you always get the full thing…

Travis Swicegood (@tswicegood) wrote at 4/9/2010 10:15 am:

@gggeek Likewise, git clone –depth allows the same thing. :-) You can’t clone a shallow repo again, hurting the DVCSness of Git, but you don’t have to download all of the history in the cases you don’t need it.

Al Kida wrote at 4/9/2010 10:48 am:

When you start using another version control system (i.e., Mercurial), will say that it’s better than Git? This just feels like a flip-flop, IMO.

Johannes (@phperror) wrote at 4/9/2010 11:05 am:

If you look in the corporate world you can’t stop at Subversion or git. Many companies use commercial systems like BitKeeper (which made big influence on git’s design) or perforce (which is cvs/svn like in some ways). IBM provides ClearCase. In the “Windows world” there’s Visual Source Safe quite often used. All of them provide some “corporate features” the other systems can’t provide. And all of them are heavily used in larger corporations. SCM – Software configuration management is more than jsut version control of (code) files.

It is likely that many corporations will choose a two tier process, where a central main repository in a proven VCS exists, probably with a support contract somewhere, but in my very personal opinion every “sane” developer will have a git clone locally available. This might be used to temporarily store work in progress or quickly browsing the history.

Brandon Savage (@brandonsavage) wrote at 4/9/2010 12:03 pm:

Al, not a flip-flop, but a learning process. I’m pretty sure that for some of the guys writing Subversion today you can find them extolling the virtues of CVS at one point; now they’ve moved on.

Developers change over time, like most people. In this case the change was much faster than others, but still a change of the mind, not a flip flop.

Herman Radtke (@hermanradtke) wrote at 4/9/2010 1:04 pm:

I have a hard time using git with compiled languages and prefer svn instead. I mentioned this on the php internals list. Maybe I should ask Travis if he has any ideas to resolve the issues I have.

On a side note:
Flamed? Some of your posts are intentionally controversial, so you should expect passionate responses. I just skimmed through the replies and did not notice any personal attacks or name calling. Hardly flames, just strong opinions.

Carlos Aguado wrote at 4/9/2010 1:07 pm:

Hi Brandon,

I guess you already know this: http://www.joelonsoftware.com/items/2010/03/17.html

If not, I suggest you take a look to it… ;-)

Brandon Savage (@brandonsavage) wrote at 4/9/2010 1:15 pm:

Carlos of course I’ve seen that. Good work from Joel. And Herman, be aware I don’t post EVERY comment that’s submitted. I post any that aren’t offensive or blatant attacks.

Herman Radtke (@hermanradtke) wrote at 4/9/2010 1:20 pm:

Brandon: That makes more sense. Thanks for keeping the comments clean. I enjoy reading both your posts and the responses.

Johannes (@phperror) wrote at 4/10/2010 5:48 am:

Herman, why shouldn’t a distributed system work with a “compiled language”? for me it makes even more sense as I more likely have to test on different configurations/systems/platforms and the general edit code ->build -> test circle takes longer which makes local, nonpublic,commits way more useful.

Steve Brosser wrote at 4/10/2010 2:31 pm:

Carlos –

Of course we’ve all seen that. And Joel is dead wrong. We’d comment on Joel’s blog to point that out that he’s wrong, but he doesn’t allow comments.

Quod erat demonstrandum.

Steve Brosser wrote at 4/10/2010 2:35 pm:

Johannes –

If you need to commit before you build and test, you’ve got bigger problems that can be solved by version control systems. I suggest you manage your own institution’s problems before you blame them on a version control system, distributed or otherwise.

Herman Radtke (@hermanradtke) wrote at 4/10/2010 6:50 pm:

Switching between branches forces me to recompile the entire application when using git. With svn, I have a separate directory for each branch. Now I could write some script that performs some magic to get around this problem, but it is not a generic solution.

Robert wrote at 4/11/2010 8:25 am:

You said “in a corporate environment”…and svn still rules there. Git is a no show.

Jonathan H. Wage (@jwage) wrote at 4/11/2010 8:53 pm:

Knowing how git works internally really helped me understand the difference between git and SVN lots better and ultimately fall in love with git. At #sflive2010 Scott Chacon from github gave us a git training and it was very interesting for him to explain to us how things worked.

Stephen Cox wrote at 4/13/2010 2:32 pm:

You know, I once said I ‘rarely used SVN (or any source control) for small projects’. But I’ve changed my mind. Now I use it for everything.. even documentation.

Pjerky (@pjerky) wrote at 4/18/2010 5:45 am:

I have used both and I can see the benefit of both, but into Git learns to play well with Windows (especially the GUI interfaces) and other non-Linux OSes there will probably not be wide adoption of this. Subversion’s cross-platform compatibility and its age and refinement are its strengths that will keep it firmly in the cross-hairs of businesses everywhere that rely on Windows for day to day operations.

I have found that working with Git is very very frustrating when doing it within Windows, which is why I use VMware player running Ubuntu to deal with Git repositories.

Copyright © 2023 by Brandon Savage. All rights reserved.