Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

No question that the majority of debates over programmer tools distill to either personal choice (by the user) or design emphasis, that is, optimizing design according to particular uses cases (by the tool builder). Text editors are probably the most prominent example--a coder who works on Windows at work and codes in Haskell on the Mac at home, values cross-platform and compiler integration and so chooses Emacs over TextMate, etc.

It's less common that a newly introduced technology is genuinely, demonstrably superior to the extant options.

Is this in fact the case with version-control systems (VCS), in particular, centralized VCS (CVS and SVN) versus distributed VCS (Git and Mercurial)?

I used SVN for about five years, and SVN is currently used where I work. A little less than three years ago, I switched to Git (and GitHub) for all of my personal projects.

I can think of a number of advantages of Git over Subversion (and which for the most part abstract to advantages of distributed over centralized VCS), but I cannot think of one contra example--some task (that's relevant and arises in a programmers usual workflow) that Subversion does better than Git.

The only conclusion I have drawn from this is that I don't have any data--not that Git is better, etc.

My guess is that such counter-examples exist, hence this question.

share|improve this question

closed as primarily opinion-based by gnat, GlenH7, MichaelT, Giorgio, Bart van Ingen Schenau Nov 17 '13 at 12:57

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
@jokoon: Efficient in terms of what? Surely not speed since even fast Ethernet is slow compared to local operations. –  maaartinus Sep 30 '11 at 20:59
2  
See this StackOverflow Q: Why to use SVN? Any hidden pros (over GIT/Mercurial/Bazaar) there? –  detly Oct 1 '11 at 5:00
1  
Much better UI (TortoiseSVN and VisualSVN rock when you work with Windows) –  stmax Jun 5 '12 at 22:17
3  
I've always thought Git was highly over-esteemed. It's a fad, and programmers are not impervious to fads - despite the many oppositions to this thought. Like everyone else in this world, everyone wants the shiny new toy (Git). Git may be good - or even great to some people - but it's never been better than SVN when thinking objectively. –  mmmshuddup Sep 24 '12 at 20:41
2  
This question was recently put on hold as primarily opinion based. That classification is wrong; note that the question was open for a long time; that there are many questions about the virtues of DVCS, and that the question doesn't ask whether it's better (opinion), but what it does better. The differences are not opinion but whether the overall product is - that's tricky (but not the point of this question). –  Eamon Nerbonne Nov 18 '13 at 10:28

20 Answers 20

up vote 176 down vote accepted

Subversion is a central repository

While many people will want to have distributed repositories for the obvious benefits of speed and multiple copies, there are situations where a central repository is more desirable. For example, if you've got some critical piece of code that you don't want anyone to access, you'd probably not want to put it under Git. Many corporations want to keep their code centralized, and (I guess) all (serious) government projects are under central repositories.

Subversion is conventional wisdom

This is to say that many people (especially managers and bosses) have the usual way to number the versions and seeing the development as a "single line" along time hardcoded into their brain. No offense, but Git's liberality is not easy to swallow. The first chapter of any Git book tells you to blank out all the conventional ideals from your mind and start anew.

Subversion does it one way, and nothing else

SVN is a version control system. It has one way to do its job and everybody does it the same way. Period. This makes it easy to transition to/from SVN from/to other centralized VCS. Git is NOT even a pure VCS -- it's a file-system, has many topologies for how to set up repositories in different situations -- and there isn't any standard. That makes it harder to choose one.

Other advantages are:

  • SVN supports empty directories
  • SVN has better Windows support
  • SVN can check out/clone a sub-tree
  • SVN supports exclusive access control svn lock which is useful for hard-to-merge files
  • SVN supports binary files and large files more easily (and doesn't require copying old versions everywhere).
  • Adding a commit involves considerably fewer steps since there isn't any pull/push and your local changes are always implicitly rebased on svn update.
share|improve this answer
45  
"Subversion does it in one way" -- I thought so too, until I started my current job. In my current job, my boss, who claims not to have trust issues, configured the server to require locking. No merging happens in our system. Files are locked on the repository and nobody else can write them without the lock. Top-down control, for those whose constitutions demand it, is definitely something svn does better than git. –  Dan Ray Sep 30 '11 at 12:16
12  
One advantage of the central repository is ease of backups. If all the checked in code is in one place, and that one place has off-site backup, you don't lose everything if your office burns down. With a DVCS, unless you do off-site backups of the developer's machines, you lose everything that hasn't been pushed to the server that's backed up off-site. –  Paul Tomblin Sep 30 '11 at 12:27
72  
Why can't git be used in a centralized manner? Just have one central repository, and your devs can clone and pull and push like they checkout and update and commit. –  David Thornley Sep 30 '11 at 14:12
18  
@PaulTomblin - Depending on workflow, Git can provide better backups. For instance, we use private github repos and I frequently push my code up to feature branches. If my coworkers do git fetch origin, each of them has a backup of my code, along with whatever backup Github itself provides. (We regularly prune merged branches, both locally and on Github.) –  Nathan Long Sep 30 '11 at 15:27
32  
You seem to imply that central is more secure for large companies or governmental work. This is simply not true. If you have a copy of the code on your computer, you have a copy of the code. It doesn't matter if it came from a central server or a central file system holding a DVCS repository. –  John Fisher Sep 30 '11 at 17:32

One benefit of Subversion over Git can be that Subversion allows checking out sub-trees only. With Git the whole repository is a unit, you can get only all or nothing. With modular code, this can be quite nice compared to Git submodules. (While Git submodules have their place, too, obviously.)

And a small tiny benefit: Subversion can track empty directories. Git tracks file contents, so a directory without any file won't show up.

share|improve this answer
8  
Working with sub trees is IMHO the only thing SVN has over GIT. Point taken, empty directories are nice, but not necessary either (and can be worked around). If git submodules and git subtree were less confusing there would be nothing holding many people back from migrating to GIT. The other advantages some people mentioned boil down to (developer) mentality. E.g. if you need top to bottom, that's fine. I wouldn't have any work for you though. –  Till Sep 30 '11 at 15:13
2  
It's funny how these are the only kinds of things that can be argued in favour of SVN (and other centralized version control) –  dukeofgaming Mar 7 '12 at 6:39
1  
Why is it funny? - Newer systems learn from older systems. There's even a benefit with RCS over git: The history files can easily be edited by hand and you can have per-file branches. But eolution involves that features are lost ... –  johannes Mar 8 '12 at 22:03
3  
I heard of a games company that uses SVN over GIT for exactly this reason - when your talking about a repository many GB in size, it suddenly becomes important! –  James Jun 5 '12 at 23:45
10  
As of git version 1.8.0, you can now use the git subtree command to accomplish exactly this. Last subversion advantage bites the dust :) Details here: github.com/gitster/git/blob/… Note: Even though this is a link to a github project, git-subtree is now part of the core git distribution. –  Carl Nov 19 '12 at 4:25

I can think of three. First, it is quite a bit easier to grok, especially for non developers. Conceptually it is much simpler than DCVS options. Second is maturity, especially TortoiseSVN on Windows. TortoiseHg is catching up fast though. Third, the nature of the beast--just an image of a filesystem where you can check things out from any level of the tree--can come in pretty handy in some scenarios -- like versioning a variety of widely different configuration files across dozens of servers without dozens of repositories.

This isn't to say we aren't moving all development over to Mercurial.

share|improve this answer
21  
Being easier to grok is an important advantage, since that makes it more likely to be used. SVN is certainly way better than no version control, and if someone is stubborn about old ways then maybe SVN is the best choice for them. –  jhocking Sep 30 '11 at 11:58
9  
@jhocking: I don't love SVN, but if someone tells me "I don't like these new DVCS things, so I'll stay with CVS", then I'll definitely recommend it: it's the easy road to at least partially sane VCS ;-) –  Joachim Sauer Sep 30 '11 at 12:10
2  
@jhocking New ways aren't always the best for every circumstance. It brings to mind the old story about NASA spending millions of dollars developing a pen that can write in 0g. The cosmonauts on the other hand made due with pencils. Sometimes the old ways are better, NOW GET OFF MY LAWN! –  maple_shaft Sep 30 '11 at 12:14
21  
@maple_shaft, and sometimes they aren't. snopes.com/business/genius/spacepen.asp –  Peter Taylor Sep 30 '11 at 12:19
2  
Easily grokked is highly subjective, and is largely based on how you try to fit the new knowledge into what you already may know. It also makes a great deal of difference what your source of learning is. If you are going by man pages, good luck. If you are being taught by a good teacher who already groks it, you've got it made. I found git made tremendous sense after watching several good videos on YouTube. If you get your understanding from someone who has already distilled it down to the simple core, then anything is easier to understand. –  WarrenT Aug 30 '12 at 23:13
  • SVN repositories are more manageable from a manager's and administrator's point of view (ACL + authentication methods + hotcopy + mirrors + dumps)
  • SVN *-hooks are easier to implement and support
  • svn:external has more power and flexibility than submodules
  • Filesystem-based repository trees are easier to use than monolithic repositories with logical-only separation
  • SVN has more different client-tools
  • SVN has third-party usable web-frontends, much better than Git's
  • SVN doesn't break your brain
share|improve this answer
14  
Doesn't break your brain? Wanna teach me how to easily merge branches with conflicts in SVN? –  WarrenT Aug 30 '12 at 23:17
1  
"Better" tools / front-ends, that's a moving target. Tools improve on both sides. None of us know what tools will be available several years from now. That assessment 10 months ago might easily change over time, and might be stale now. I would prefer to see substantive answers. –  WarrenT Aug 30 '12 at 23:23
3  
Tree conflicts? Check. Yes or no to all options? No. Svn is designed to infuriate. Clean working copy command? No. Revert cannot clean unversioned files. –  Warren P Nov 16 '13 at 15:10

I wrote this as a comment on somebody else's answer, but I guess it deserves to be an answer in and of itself.

My company's carefully-chosen configuration for SVN requires file-level locking to edit content, and never ever ever uses merge. As a result, multiple developers contend for locks, and it can be a major bottleneck, and there's never ever any chance of a merge conflict.

SVN definitely does top-down managerial control better than Git. In my skunkworks migration to Git (asking forgiveness rather than permission) I've terrified my manager many times with the notion that there isn't any software-enforced central master controlling server to which we are all slaves.

share|improve this answer

This is all relative, and like maple_shaft said, if one works for you, don't change!

But if you really want something, I'd say it is maybe better for designers, web programmers and such - it handles images and binary files a bit better.

share|improve this answer
2  
How does SVN handle them better? Git considers every file a BLOB. –  WarrenT Aug 30 '12 at 22:59
3  
@WarrenT because of the workflows, with git you're branching and merging a lot (or why bother using it) and you just can't realistically merge binaries. Hence, you often put the "needs lock" property on binary files in SVN. –  gbjbaanb Oct 19 '12 at 19:03
1  
Some binaries can (theoretically) be merged, e.g., an ODT document. –  Donal Fellows Mar 27 '13 at 10:32

My reasons:

  • maturity - both the server, and the tools (e.g. TortoiseSVN)
  • simplicity - less steps involved, a commit is a commit. DVCS such as Git and Mercurial involve commit, then push.
  • binary handling - SVN handles binary executables and images better than Git/Hg. Especially useful with .NET projects since I like to check build-related tools into source control.
  • numbering - SVN has a readable commit numbering scheme, using just digits - easier to track revision numbers. Git and Hg do this quite differently.
share|improve this answer
1  
"commit numbering scheme" is only possible if you have canonical trunks. Otherwise which one gets the major numbering? –  user1249 Mar 10 '12 at 13:32
1  
+1 the numbring in svn. This number is unique. there are tools to use this number as part of the app-versionnumber xx.yy.zz.12882 where 12882 is the svn version-number. If there is a production problem you can ask vor the versionnumber and you have the exact svn-revision where the software was build with –  k3b Jan 7 '13 at 18:57

I appreciate that you are looking for good information, but this kind of question just invites, "I think Git is so much win, and svn teh suxorz!" answers.

I tried and personally found Git a little too much for my small team. It seemed like it would be great for a large distributed team or group of teams that are geographically dispersed. I understand greatly the benefits of Git, but source control in my opinion isn't something that keeps me up at night.

I am a deer hunter, and when me and my friends go out they are armed to the teeth, bristled with ammo and high tech gear. I show up with a single rifle, seven bullets and a buck knife. If I need more than seven rounds then I am doing something wrong, and I do as well as anybody else.

The point I am trying to make is that if you are a small team working on a medium to small project and you are already familiar with SVN then use it. It is certainly better than CVS or (shudder) SourceSafe, and it doesn't take me more than five minutes to set up a repository. Git can sometimes be overkill.

share|improve this answer
3  
Really? Then I'd suggest you have a look at fossil. –  Spencer Rathbun Sep 30 '11 at 12:39
5  
let's not sound the alarm at the slightest possibility of controversy. Important topics are often the most controversial and the ones most likely to invoke strongly held views. So "This kind of question" is important and the possibility of an out-of-bounds response is not a plausible to not post it. I assume the users on this Site are adults. What's more the way my Q was phrased, was if not neutral, then deferential to subversion folks--responsive answers to my Q will have to recite advantages of subversion over git, not the other way around. –  doug Sep 30 '11 at 12:39
9  
@Spencer - Contrariwise, as a user of both git and hg, I would suggest mercurial for anyone who thinks git is too much. TortoiseHG would be very familiar to anyone used to TortoiseSVN (it even shares the same Explorer overlays on Windows). It's certainly a lot easier than VSS and I would be surprised if it took more than a few seconds to set up an hg repo, commit the initial state and clone it to a shared drive. –  Mark Booth Sep 30 '11 at 13:16

When you don’t need to branch and merge, SVN (with TortoiseSVN on Windows) is very easy to understand and use. Git is overly complex for the simple cases, as it tries to making branching/merging easy.

(A lot of small projects never have to branch if they are managed well. Git is aimed at the complex cases; therefore most Git documentation assumes you need to do complex operations like branching and merging.)

share|improve this answer
6  
Using git branching and merging are no complex operations. I even use branches in a one-man project, even when there are no requirements for multiple version. Keeping work you can't continue at the moment in a branch, branching when you find out that trying another solution may be much better... However, I agree that git is a bit harder to learn. –  maaartinus Sep 30 '11 at 21:16

Usability. It's not really Subversion's merit but rather TortoiseSVN's.. TortoiseGit exists, but it still has a long way to go to match TortoiseSVN.

If you asked what Git does better than SVN I would reply GitHub. It's funny how third-party tools make such a huge difference.

share|improve this answer
1  
Assembla (for any supported SCM - SVN in list) is better than github, I think –  Lazy Badger Oct 1 '11 at 6:56

Well, my grandpa could use SVN on his Windows XP computer, but he'd have trouble using Git. Maybe this is more an accomplishment of TortoiseSVN over TortoiseGit, but I think it's rather tied to the fact, that Git is inherently more powerful and thus more complex, and it would be pointless to dumb it down to the same level.

Now it doesn't really matter for my grandpa, because he hasn't done any programming as of late. However, I was once on a team, where our graphic artists were using our source control as well.

And those are people who simply expect their tools to work (so do I, but I have a realistic chance to get them to work in case of failure) and be intuitive. Apart from the fact, that it would had been quite an effort to get them to get along with a DVCS, there was little to be gained. And with only two programmers in the team, it made sense for us to also just stick with SVN.

share|improve this answer

At work I couldn't switch the developers from SVN to any DVCS for two reasons:

  • Partial checkouts (like only three folders from different depths in the project tree)
  • File locking (binary format reports)
share|improve this answer

Other people have posted some pretty good answers, but what about Permissions? Using Subversion over SSH, you can make a separate account on your server for SVN. Different developers can be given different access to different parts of the repository. Can GIT do that? I guess there is gitolite, but it just doesn't seem as flexible or robust to me, nor do I know anyone who is actually using it.

share|improve this answer
2  
Others have hit this in mentioning "top-down managerial control". This is a key element for my environment - we have certain areas of our repositories that need to be locked down to read-only or even no-read for some user groups. We also need to have a single location we can point at and say "this is the authoritative master copy, if your copy doesn't match what's here, it's not official." –  alroc Jan 7 '13 at 19:23
1  
blessed repository of the project lead and lieutenants is giving control over who can commit. Git repo published on http-auth enabled server (using the same apache modules svn does) do authentication and say who can clone/checkout what. Sure, it's not as granular as svn per directory permissions can be, but to me it looks more like micro management than actual need. –  Hubert Kario Jan 7 '13 at 20:17

I post this as a response rather than a comment.

I admit than DVCS are quite in the trend right now, but I'll try to tell why.

DVCS are better because just like lots of people have been saying, "this is the way we should have been working from the beginning". It's true, you can do with a DVCS what you used to with SVN, so in a way that makes SVN obsolete.

However, not every software project is as good as it gets:

  • Long term project have a lot benefited from DVCS, because it uses less overhead, allows much better management (branching etc), and is greatly supported by hosts like google code and github.

  • Those projects are not the only ones, there are other kind of projects that are being developed in companies without any assistance from the outside world or internet: everything is done internally, and often on a short term. A good example: a video game. Code evolves rapidly.

For the latter case, developers don't really need branching or sophisticated features DVCS can offer, they just want to share source code and assets. The code they make is not likely to be reused, because there is a deadline. They rely on SVN rather than a DVCS because of several reasons:

  • Developers have machines that belong to the company, and this might change rapidly. Configuring a repo is a loss of time.
  • If those guys don't have their own machine, they are less likely to be working on the same source code/part of the project. Plus one for the centralized data.
  • network speeds and big money allows the use of a centralized server that deal with everything SVN, it's bad practice but backups are made etc.
  • SVN is just simpler to use, even if it's the wrong way: synchronizing files on peers without redundancy is not a simple problem, and "do it the right way" just cannot make it in time if you always want it to be perfect.

Think about the game industry machine and how SVN is a time saver; people communicates much more on those projects because games are about repetitive programming and adaptive code: there is nothing hard to code, but it has to be done the right way, ASAP. Programmers are hired, they code their part, compile it, test it a little, commit, done, game testers will deal with the rest.

DVCS are made for the internet and for very complex project. SVN are for small, short term, tight team projects. You don't need to learn a lot from SVN, it's almost a FTP with a dumb diff.

share|improve this answer

Speed. Sometimes takes 10 or 15 minutes to clone a big git repository, while a similar sized subversion repository takes a couple of minute to check out.

share|improve this answer
4  
But checkout/cloning is a rare operation. In most scenarios, git is faster than subversion. –  rds Nov 9 '11 at 11:16
2  
git clone --depth=1 is your friend if you don't care for history –  Hubert Kario Jan 7 '13 at 14:53
  • Sense of security when doing an 'svn commit'. Since commits go to the server, there's no possible screwup that I can do that will erase my changes after they are committed. In git, commits are local, so until I push, a stray 'rm -rf' and it's all over.
  • Commits are authenticated. By default in git I can tell it I'm committing as anyone.
  • Fewer commands to learn for everyday use. 'svn checkout', 'svn up', and 'svn commit' will get you pretty far.
  • Shared checkouts work a lot nicer. When you go to commit, it asks you for your username/password, you don't have to remember to pass certain command line arguments. Sometimes at work we have a shared machine with a shared svn checkout of some project. Someone might say "Bob can you look at this on this machine" and he can, and he can commit his changes as his user without any screw ups.
  • Repository layout. You can have an umbrella project and subprojects and choose what to check out when.
  • Revision numbers are incrementing integers.
  • Designed for the central repository workflow.
share|improve this answer

Subversion and Git both encourage particular (and very different) approaches to development and collaboration. Some organizations will get more out of Git, and others will get more out of Subversion, depending on their organization and culture.

Git and Mercurial are both excellent for distributed and loosely organized teams of highly competent professional programmers. Both of these popular DVCS tools encourage small repositories, with reuse between developers taking place via published libraries with (relatively) stable interfaces.

Subversion, on the other hand, encourages a more centralized and tightly coupled management structure, with more communication between developers and a greater degree of organizational control over day-to-day development activities. Within these more compactly organized teams, reuse between developers tends to take place via unpublished libraries with (relatively) unstable interfaces. TortoiseSVN also permits Subversion to support multidisciplinary teams with members who are not professional programmers (e.g. systems engineers, algorithms engineers or other subject-area specialists).

If your team is distributed, with members either working from home or from many different international sites, or if they prefer to work alone and in silence, with little face-to-face communication, then a DVCS like Git or Mercurial will be a good cultural fit.

If, on the other hand, your team is located on a single site, with an active "team" approach to development, and lots of face-to-face communication, with a "buzz" in the air, then SVN may be a better cultural fit, particularly if you have lots of cross-disciplinary teams.

Of course, it is possible to configure Git and Hg (powerful and flexible as they are) to do pretty much whatever you want, but it is definitely more work, and they are definitely harder to use, particularly for those members of the team who would not naturally be inclined to use any form of version control whatsoever.

Finally, I also find that sharing functionality using "hot" library development under Svn (with CI & a test-driven approach) permits a pace of coordinated development that is difficult to achieve with a more distributed and loosely-coupled team.

share|improve this answer

There are two major trends in version control right now; Distribution, and Integration.

Git is great at decentralization.

SVN has lots of tools built that integrate with it. It's common to set up your SVN server so that when you check in a fix, you mention the bug number in the checkin comment, and it automatically sets that but to an "in testing" state, and alerts the assigned tester that they need to look at it. Then you can tag a release and get a list of all the bugs fixed in this release.

The tools that do this with SVN are mature, and used every day.

share|improve this answer

Below are the two reasons that I still stay with SVN.

  1. The learning curve. SVN is easier than Git, even the setup (server or client too), usability, and commands.
  2. Better server packages like Subversion Edge, VisualSVN, uberSVN etc.
share|improve this answer

In Subversion, you can edit log messages (also called "commit messages") after the commit is done and pushed. For most practical uses, this is impossible by design in decentralized systems, including git. Of course, in git you can do "git commit --amend", but that doesn't help you after your commit has been pushed elsewhere. In SVN, when you edit the log message, you're doing it on the central repository that everyone shares, so everyone will get the edit, and without the revision's identifier changing.

Editing log messages after the fact is often very useful. Aside from just fixing a mistake or an omission in a log message, it enables you to do things like update a log message to refer to a future commit (such as a revision that fixes a bug or completes the work introduced in the current revision).

There need be no danger of losing information, by the way. The pre-revprop-change and post-revprop-change hooks can save a history of the old messages if you're really concerned, or send out emails with the log message diff (this is more common, actually), so that there's an audit trail.

share|improve this answer
1  
this is also straightforward to do in git; e.g., git --amend; another way to do this is via git reset --soft HEAD^, which just walks back but doesn't alter the index, and so you can edit/re-write the commit message. –  doug Nov 17 '13 at 0:03

protected by Mark Trapp Oct 2 '11 at 11:14

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.