Why Subversion Still Beats Git

Note: This post is outdated, and has been superseded by Git Versus Subversion: A Reconsideration.

There are lots of projects heading over to Git these days. It’s not hard to see why: Git offers great merging support, distributed version control, and a great playground. Spots like Github even offer centralization crucial to large open source projects. But when it comes to the corporate world, Git may not be ready for prime time.

Corporate America needs a centralized version control system. Subversion still offers this: Subversion centralizes the repository and simply checks out a working copy (versus Git, which gives you a complete repository). Corporate America still needs to have cannonical version numbers, and the ability to see the progress of a product over time as a single line – not a bunch of branches and independent repositories.

Git is a great piece of software. It is fantastic for distributed version control. It is my opinion that when it comes to corporate work, Subversion will still continue to win out

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

pcdinh wrote at 1/14/2010 1:42 am:

Agreed. Subversion wins when numeric version numbering does make sense. I still prefer Subversion than Git. It is very suitable for those who works in a centralized manner.

Mathieu (@Mathieuk) wrote at 1/14/2010 2:09 am:

I agree, but that is no reason for a developer not to use git. By using git-svn you get all the benefits of git ( and there are quite a few, imho the best one is the painless branching ) and still have the ability to push to a centralized subversion repository.

robo47 (@robo47) wrote at 1/14/2010 3:12 am:

Do all those arguments really speak against git ?
Git is not svn, but it can in many cases be used like it.

For canonical numbers, yes, that’s nothing git provides.
And yes, there are no working copies, only clones of the complete repository when using only git.

But why is having a central server against git ?
Using git with a central server where everybody commits to (after local work is done) isn’t a problem or ? You can do that, but you just aren’t forced to.

And since nobody forces the users to have all their working/testing-branches pushed to the central-server too, there will in fact be only one timeline too where you can see you progress.

And since there exists git-svn, it wouldn’t be a problem to use the best of both world, one central svn-server and let the users choose if they want to use svn or git via git-svn, if you really need the canonical version-numbers.

When using git-svn it is too possible to NOT do a complete clone, but just say a clone of everything after revision X.

Nicolas BUI (@nicolasbui) wrote at 1/14/2010 3:51 am:

The only field where Subversion beat Git is the GUIs avalaible. So, I do not agree that Subversion beat Git because of corporate.

As a freelance, I’ve done many many mepositories migration mission for companies in the past from CVS to Subversion and VSS to Subversion.
There are many risk when migrating (repo integrity, users, …), so corporates are prudent and nervous about when migating to other systems.
So cautiously, if the current SCM work nice and have no trouble for them, why would they take the risk to switch ?

For my past client in insurrances(3 years ago), the decision to leave VSS in favour of SVN was the branch/tag management performance (comparing VSS to SVN).
But for the sake of the users (+200), the process took more than 6 months for migrating, forcing SVN to do some weird use habit of VSS and trainings. So previously, I’ve ask them if they plan to switch to Git one day. And the reply was “SVN actually work nice for our actual use, thanx to the available GUI, Git has a differents philosophies, so switching to Git would be a difficult task… so it’s not for us yet”

Simon wrote at 1/14/2010 5:57 am:

I’m a shade confused – why “Corporate America” specifically? Do you believe that developers in other nations do not use VC?

Parochialism aside, I agree that what is becoming clear about Git is that any non-trivial project will end up having a centralized repository anyway, which rather flies in the face of the – perhaps misguided – dream people bought into regarding distributed VC.

David wrote at 1/14/2010 6:02 am:

No mention of other DVCS?
Bazaar has canonical version numbers, and allows for the checkout of only a working copy if desired.

Hans wrote at 1/14/2010 7:10 am:

I’m pretty sure that DVCS is coming to corporate America (and probably “corporate OTHER-COUNTRY” too). Of course, I don’t know whether it will be Git, Mercurial, Bazaar, Darcs, etc. that wins consensus — and I am sure it will be adopted slower because it’s a bigger paradigm shift than CVS -> SVN. Certainly small, all-local organizations with short-lifecycle projects are not going to reap as many advantages as larger organizations with dispersed work forces or organizations with large development trees or maintenance cycles. But I think software-writing corporate America is a lot more of the latter.

I think there are a couple issues with the arguments here:

– Git does have canonical version “numbers”, right? — they’re just SHA1s instead of integers. Advantage of being unique across repos in addition to within.

– The centralized server is a non-issue, because Git/Mercurial/etc. support this just fine. (This is how Hg on Google code or Sourceforge works, for example.) It requires one extra step (i.e. “push”), but really is no different from SVN.

– Developers with SVN already do their own “branching” on a micro scale. When I’m forging off on some new code direction and *not committing* for a day or two because I want to leave the canonical copy in a working state, I am basically branching without the aid of version control. I would much rather have a DVCS that I can commit to throughout the day and then push when work is complete. DVCS even would allow me to work with other people on my branch, if they needed to grab the latest & greatest to see whether they’re changes will work with the new codebase.

Now, DVCS is a bit of a paradigm shift; developers will have to understand that “it’s not backed up until you push”, etc. And the tools need to catch up (but this is only a matter of short time now, as plugins are available for Jira, Trac, etc.) But I think these systems offer so many efficiency advantages for large teams and large codebases that I cannot imagine how they could possible /not/ eventually take hold in corporate world.

P.S. Apparently Fog Creek uses Mercurial internally.

Matt Farina (@mattfarina) wrote at 1/14/2010 11:12 am:

The centralized repo is a big deal in corporate America for a lot of reasons. This is one place I like Bazaar. You can do the central workflow with the Bazaar and still reap the distributed benefits.

That being said, Bazaar isn’t there yet and I use both it and git.

sapphirecat wrote at 1/14/2010 11:41 am:

This one came up briefly in my last interview. “For a business, I would recommend Subversion,” I said. Why? Because DVCS allows for K workflows, of which only one will be officially supported. SVN places more restrictions on that choice, which translates to fewer ways to screw the whole thing up. This is what the businesses I have dealt with prefer.

And in the end, *having* a VCS matters far, far more than *which* VCS.

chuck wrote at 1/14/2010 2:17 pm:

You might want to check out git tag. this lets you create a pointer to any sha1 that can be checked out; solving your cannonical version numbers. Even better, name a branch to your version number .. branch v1.1.0.0.9 … seriously easy. did you even research this article?

if you want a ‘central’ point (you already mentioned github), well you can fork a project instead of sharing it. Your ‘live’ version is main repo and each developer/team/whatever has their own fork of the project, completely separate. when the ‘central’ hub is happy, they can do a pull request and only pull the parts they need.

or, like in the old days you can make use of git format-patch and send around changes which can be merged to the main repo

just because this isnt default behaviour doesnt mean it cant be done.

@nicolasbui have you tried gitx / tortoiseGiT? both very good guis.

@Giuseppe there is no need for central point; you can push to anyone via ssh, your server, your colleagues laptop etc. you can commit regularly while offline with dvcs, commits in svn require upstream.

@David but Bazaar is slow & its branching is poor

@akrey yeah, apparently the op didnt bother to look up anything about performance regarding binaries or massive files

@sapphirecat with svn *everyone* will be checking in on same branch (as svn branching is poor), even those wacky far out changes that havent been tested. with git you can just put it on a new branch and not worry about it breaking everyone elses version of the project or your live environment.

Eddie Wilson (@eddit) wrote at 1/14/2010 4:00 pm:

Doesn’t Git offer all of the same things you mentioned in the centralized repository (github for example)? Git just allows you to also have a repo locally.

IMO this is just a perspective issue. Git allows you to screw up locally, fix, and then push an update. Subversions requires you to push all of the screw ups if you want them to be tracked. I’d rather track my tooling around locally, get it straight, and the share with the rest of the team. Having a local repo is like a breakdown of commits between teach commit that’s worthy (which you push to the central repo). It’s the best of both worlds.

Please correct me if I’m wrong on this. I use git locally for projects, and have used it a handful of times with another team and a centralized repository on github.

Trevor Burnham (@trevorburnham) wrote at 1/14/2010 4:03 pm:

It sounds like you haven’t heard of Gitosis: http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way

Gitosis uses public key authentication to identify committers and secure their interactions with the repository on the server. It’s fairly easy to set up, once you have everyone’s public keys—which should be trivial in a corporate environment.

By contrast, there doesn’t seem to be an agreed-upon way to secure a Subversion repository. It’s possible to do, but tedious to set up. So, I’d argue that Git is, if anything, more well-suited to corporate environments where security is critical.

Morgan wrote at 1/15/2010 2:31 am:

Greetings,

Check out:

git describe –tags –long

This gives you a string like (in the case of one of my projects)

2.1pre5-4-g675eae1

which is formatted as

{last reachable tag name}-{# of commits since that tag}-#{SHA of HEAD}

This gives you a ‘canonical version number’ (spelling corrected) that is monotonically increasing by commits, and unique across multiple repositories of development. If we’re all on the same HEAD, it will return the same value. If we all share the same most-recent-tag, but have different commits, the SHA will be different.

This completely replaces Subversion commit numbers for me, and everybody I’ve explained it to.

Subversion is really completely unnecessary; git can be used as a centralized system, and provides all the capabilities of Subversion, and more.

Or, as Annie Oakley put it, “Anything you can do I can do better; I can do anything better than you.” :)

— Morgan

sapphirecat wrote at 1/15/2010 9:14 am:

@kurko: when developers start coming to interviews knowing what a VCS even *is*, maybe even how to use one, I’ll think about it. Until then, the *simplest* thing that works is the obviously correct choice.

Daniel (@dlibanori) wrote at 1/15/2010 11:06 am:

Fact: Git > SVN

I understand some people like SVN, but technically speaking, Git is better then SVN:

1-) Branches and merges do work.
2-) You may work centralize, you may not. You choose. And multiple choices is not a bad thing.
3-) Git is faster.
4-) Cannonical version number doesn’t mean anything meaningful. Tag does.
5-) If you want to try something new you would like to have your own repository.

There is real Git flaw: Windows support.

Jeff Dickey (@jeff_dickey) wrote at 1/16/2010 2:24 am:

@sapphirecat – Precisely. Why brag about your skills in Agile, which basically preaches “do the absolute simplest thing that can possibly work – and ONLY that much”, and then declare “We’re going to use a tool that’s very good at one thing for something that’s subtly but critically different – maintaining the IP of this organization in a centralized, auditable, securable fashion”? I know people like to shoot themselves in the foot, but when they start doing so with AK47s, it just means someone else has more of a mess to come clean up later.

Herman Radtke (@hermanradtke) wrote at 1/16/2010 4:17 pm:

At my corporate job we use git. Each issue has a ticket # and we put the commit hash in the ticket number. We sometimes tag a large number of commit hashes with a ticket number. This is really only useful to those using gitk to track history.

No one outside of development has any interest in commit hashes or version numbers. Tickets are tied to builds and that is how development is tracked.

Copyright © 2023 by Brandon Savage. All rights reserved.