Subversion or Git? Decisions, decisions ….

Are you facing a difficult choice between version control systems? Are you having trouble sorting out the alternatives? Are you bewildered by all the opinions you find on Google? Let’s see if I can help sort this all out.

CollabNet (the original stewards of the Subversion project) provides both Subversion and Git, either through our enterprise TeamForge product or through our CloudForge Platform. We think there’s a place in the universe for each. Here’s how to find yourself in that universe.

Git or SVN



The short form

Here are some specific recommendations. If you want to stop reading at the end of this section, you should make out just fine.

  • If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But you can’t do anything else with Subversion (slip-ups or no), and “compelling requirements” like Sarbanes-Oxley are happier with guarantees than possibilities.
  • If you plan to maintain parallel, largely shared but permanently somewhat different lines of the same product, use Git. One common example: perhaps you have a large product that you customize for each customer. The customizations are permanent, and generally not shared among code lines, but most of the code is common to all. Git was designed for just this case (in Git terms, local customizations to the common core, and occasional feature or bug-fix contributions back up-tree).
  • Neither of those? Take your pick, you should be fine with either tool.

The Basics

What do you want from your version control system? A lot of this is the same for everyone, and both tools accomplish these tasks just fine. If all you care about is the basics, you could easily just flip a coin and get on with your work, confident that your choice would be sound. These “basics” include:

  • Store all versions of your files (“version control”)
  • Associate versions of each file with appropriate versions of all other files (“configuration management”)
  • Allow many people to work on the same files, toward a common goal or release (“concurrency”)
  • Allow groups of people to work on substantially the same files, but each group towards its own goal or release (“branching”)
  • Recover, at any time, a coherent configuration of file versions that correspond to some goal or release, either for investigation or extension like bug fixing (“release management”)

Both systems do all these things quite well. If these things are truly all you care about … flip that coin! All the discussion and decision has to do with other details, details that are always secondary to the basics, but can become crucial to particular projects or environments.

So, if you haven’t flipped that coin and gone away, let’s look at the differences.

But first, some demythologization

Here are a few things you may have heard that just aren’t true, or aren’t true any longer:

  • Git hates windows. No, it doesn’t. It used to, but now there are good Git integrations with Windows Explorer (TortoiseGIT, SmartGIT) and most of the major IDEs  (Visual Studio, Eclipse, Netbeans), and you no longer need to use the Unix emulation environment Cygwin.
  • Git is only for hackers. As a  Unix-centric, command-line only tool, Git was originally anathema for many workers. But with all the GUI integrations, it’s considerably more friendly, within reach of nearly everyone (see Windows integrations above, plus non-Windows tools like GitX, Coda via GitX or Tower, Emacs).
  • Git is hard to learn. Well, it’s a lot easier to learn now, anyway, thanks to those GUIs, and to improvements in the command-line UI and documentation.

On the other hand

  • Subversion is slow on Windows. The latest Subversion releases, up to the current 1.7, have made great strides in Windows performance.
  • Subversion merging is hard. Well, it’s a lot easier now, anyway, thanks to the continuing progress on “merge tracking.”

So, what’s different?

As you’ve surely heard, the key difference is that Subversion is “centralized,” while Git is “distributed.” You can go many other places to learn about what that means in their implementation, I don’t spend time on that here. But I will talk about why it matters to you.

Local versioning

Git’s distributed model means that you have full version control operations purely locally on your workstation. Of course, the changes you make locally are not visible to anyone else, until you do something else (Git’s “push” or “pull”), but you can check changes in so they’re not lost, create branches, merge among branches, back up to older versions, and browse and compare versions — all without a network. The one cost in all that is, you have to learn some additional commands (push, pull, clone) and workflows, if you ever expect anyone else to see your work. You can do everything locally that any version control system can do … and you also have extra steps required to make your work visible to others, kind of an inescapable trade-off. On balance, local versioning is a significant convenience for the developer, and a big part of the popularity of Git.

Guaranteed centralization

Most processes have some reason to want one copy of everything, somewhere, that’s reliably known to be “the official version.” With Subversion, that’s the central repository. With Git, that’s … some repository or other: the tool doesn’t privilege any one repository over another, but users and conventions can. With Git, you have to remember to push or pull all changes into the designated central repository — not hard to remember, especially if you support it with other conventions, such as only building releases from the central, but still an extra step. With Subversion, there’s nothing to remember or agree to: there is only one repository. By definition, anything that’s checked in at all is checked in to the central. One place where this can become particularly important is in “governance,” where external constraints like Sarbanes-Oxley or escrow contracts demand hands-off guarantees. On balance, enterprises with governance constraints value the guarantees of Subversion.

(Governance, traceability, ALM, and DevOps all require broader support than just the code and files, of course: there has to be integration among the code repository, the tests, the deployed product, and the tracking system. Fortunately, CollabNet now integrates both Subversion and Git with these other components.)

Throw-away work

Somewhat paradoxically, there are times when you want to throw away (or keep private) some work. Git is better at throwing things away than Subversion is: you keep the potentially throw-away work in its own repository until you decide whether to make it official. If you decide to toss it, there are virtually no left-overs in the repositories you keep. By contrast, in Subversion, everything goes into the one central repository, and you don’t have that same option. Typically in Subversion, you don’t actually “throw away” such work, but only leave it on some branch you never look at. But it’s still there, taking up space, and possibly cluttering the history browser. The possibility of throw-away work is a fairly big consideration in open-source work (and in fact it was one of the key design considerations for Git), but rather less so for enterprise work (where throw-away work is also throw-away salaries, equipment, lighting, and all the other employee expenses), so enterprises typically avoid ever doing it in the first place. I wrote about handling throw-away work at some length a while back.


Some things are possible, but I wouldn’t recommend them — at least, not to someone who has to ask:

  • Git-SVN. Git is able to pull files out of a Subversion repository, store them in a Git repository (allowing all that local version control, and some inter-git-repository push/pull/merge), and then push the results back into Subversion. It sounds like the best of both worlds, doesn’t it? But you end up having to be an above-average expert in both systems, and parts of the workflow are very slow. Some folks really like it. Maybe you would, too. But it’s not what you’d call “mainstream.”
  • Cygwin. Cygwin is a system for providing a lot of Unix-like capabilities on a Windows system. Early Git Windows implementations ran inside Cygwin. Again, this ends up forcing you to be an above-average expert in two very different systems. If you’re already steeped in Unix and Windows both, it can be handy. But it’s a high price to pay for just adding a little Git. Fortunately, Git Windows installation no longer requires Cygwin.

So, which one’s for you? Try a free, fully functional 30 day trial of Subversion and Git on CloudForge to help make this choice.

Tagged with: , , , , ,
Posted in CloudForge, Git, Subversion
7 comments on “Subversion or Git? Decisions, decisions ….
  1. Rick Beacham says:

    For me GIT on cygwin in windows just makes more sense and FOR ME plus it was easier to set up.

    I used SVN in college and it was similar to GIT but GIT is much more mainstream now. And i think its easier to fix. I would use both. And still have a back up copy on a Amazon bucket maybe.

    • Jack Repenning says:

      Cool! What is it about GIT/cygwin that particularly fits for you? For example, are you already committed to the cygwin pseudo-Unix environment anyway?

      And what sort of “fixing” were you talking about?

      • Rick Beacham says:

        If one person commits before pulling new changes then in Git you can easily fix by merging i think. I would say i’ve used WIndows much more in my lifetime. But i prefer the Unix Command line then DOS. T In the MINGW32 window i can easily move to the GIT Repo and then simply type GIT GUI. THen i just do the normal git commits and after i just push through the command line in ming. ITs by far the easiest way i found. Its also the easiest to set up. ON my mac i do it a little different since GIT GUI does not work. ON linux i’m not sure. But my friends on linux do it very similar and its free. If you know of a better solution on windows for GIT then please let me know. For SVN which is what my University tried to teach us, it was hard to set up correctly. But i’ve used GIT professionally and such have more experience with it so i’m sure i’m just biased… 🙂 I really think it would be better for Universities to start teaching SVN or GIT or require the students to use it. It just makes sense to use the tools. Especially when your dog might eat your PC..

        • Jack Repenning says:

          Huh. Interesting example.

          If a team are using git, and one worker commits then pulls other work in, the potential conflicts are generally handled well by git’s automatic merge included in the pull. Problems can arise (you and I both change the same line in incompatible ways), and git’s conflict resolution is roughly like Subversion’s: you get access to the various “before” versions, and (for a text file) the tool’s guess at the merge match-ups (with “conflict markers”). Probably just due to my history, I generally fine the git conflict-marking to be weaker than Subversion’s: much more likely to match up inappropriately, effectively moving stuff around.

          But in contrast, if this team were using Subversion and the same botch occurred … it couldn’t occur! 😉 Subversion requires the “svn update” (analogous to the “git pull”). This is a bit heavy-handed: it does prevent some really horrifying conflict-resolution messes, but such things are pretty rare. And this protection comes at the cost of “speed-braking” every commit, constraining it to these more-cautious rules and slowing operations while svn checks with the repo to see if there’s any risk.

          For this scenario, it seems to me like the comparison works something like this:

          – For the most common cases, git is faster (because local), more flexible (because of all that handy local versioning).
          – For the next-most common case, of merge conflicts that can be resolved automatically, git seems to be slightly better (that is, can automate more kinds of resolutions).
          – But for the quite rare cases where a human needs to make the judgement, git seems weaker: the conflict-marked merged-diff file is more prone to false matches and dumb mistakes, requiring more and more complicated hand edits to reconcile.

          And of course, there’s a lot to be said for being better at the common cases.

          • Rick Beacham says:

            Yes, I think you make an important point that i did not know about. And i’ve seen the problems with GIT you mentioned first hand. Maybe SVN is a better choice in my case. Can you use both?

          • Jack Repenning says:

            It is possible to use both at once. I actually do that, for one of my repositories: I’m thinking of migrating it from SVN to git, so this allows me to compare the two on exactly the same data and operations.

            What I’m doing is to commit every change into both repositories. The two tools play with each other pretty well — for example, each knows not to try to version the other’s admin directories.

            Some people have used git for local work, and SVN to promote changes to a group directory (gaining the personal flexibilities of local versioning, while retaining the enforcement and auditability of a central repository). There’s even a plugin for git, git-svn, that includes support for this model.

            But I don’t think anything like either of these helps the merge-conflict situation any … rather the opposite: one way or another, you have to satisfy both systems. If anything, using them both makes it more likely you run into a rough spot of one or the other tool.

  2. LiuYan 刘研 says:

    maybe offtopic: i really like the serial version numbering of each file in CVS. SVN and GIT does not have a version number for a single file. Version numbering in SVN is better than GIT for me, because it’s decimal number, each for human reading/remembering than the “random” hex string version number in GIT. (sorry for my English)

3 Pings/Trackbacks for "Subversion or Git? Decisions, decisions …."
  1. Quora says:

    Which is better, SVN or Git?…

    A great answer to this question was recently written about by Jack Repenning here: * If you have compelling requirements for a single, certain, master copy of your work, use Subversion. You can do this with Git, so long as there are no slip-ups. But yo…

  2. […] I turned to GUI tools, hoping for extra insight. After all, Git has GUI tools, right? I read that somewhere, […]

  3. […] I think tools like CollabNet’s TeamForge and Microsoft’s Team Foundation Server are on the right track by adding DVCS (in this case, Git) support to existing enterprise-class ALM tools. Access control, issue tracking, and the capability to integrate with other important pieces of the ALM workflow (say, Meister and Deploy+) more or less completes the tooling puzzle, but even still, Microsoft and CollabNet will both tell you the move to DVCS is still not for everybody. […]

Leave a Reply

Your email address will not be published. Required fields are marked *