300

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
doug
  • 558
  • I guess one of the main point you can make is that SVN is much more efficient in a local network. – jokoon Sep 30 '11 at 20:49
  • 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
  • 4
    See this StackOverflow Q: Why to use SVN? Any hidden pros (over GIT/Mercurial/Bazaar) there? – detly Oct 01 '11 at 05:00
  • @maaartinus I'm sure that you could use SVN via local operations as well. :-) – tehnyit Jun 05 '12 at 17:12
  • 1
    Much better UI (TortoiseSVN and VisualSVN rock when you work with Windows) – stmax Jun 05 '12 at 22:17
  • 1
    Another close duplicate from SO: What can git NOT do, that svn can do? – sleske Jul 16 '12 at 12:30
  • 4
    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. – bought777 Sep 24 '12 at 20:41
  • 3
    I thought SVN still good to use, the learning curve is good then GIT. – Cheung Nov 09 '12 at 08:13
  • 1
    @mmmshuddup: In git, creating a patch series, going back to it, editing a second commit in 5 commit series and creating a new set of patches is easy. With svn is basically impossible (you need to use external tools). If you have proper code review (and only few people can push to upstream) it's a godsend. I'd still use it as an interface to SVN if it was the only feature it had. – Hubert Kario Jan 07 '13 at 14:22
  • 5
    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
  • 1
    Many good questions generate some degree of opinion based on expert experience - A perfect description of most of the answers here. I don't understand why it was closed, either - be critical of the bad answers, don't punish the questions for bad answers. Can't wait until I can VTRO... – Izkata Nov 18 '13 at 12:46
  • 1
    closed because "opinion-based"? i'll have to just concede defeat here--i'm just unable to successfully navigate through the mods' scylla and charybdis of "opinion-based--closed" and "RTFM" (aka "let me google that for you"). Seems to me those two constraints, broadly interpreted as they are, can be used to toss out just about any question on any given day. – doug Oct 06 '15 at 05:42
  • Even for personal projects, git gives the decisive advantage of providing all the history on your laptop, even without network connection (with some remote git or svn server). – Basile Starynkevitch Jun 23 '17 at 10:18
  • See https://svnvsgit.com/ for a full comparison – Erik Aronesty Aug 05 '19 at 16:47

20 Answers20

209

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.
Bill Garrison
  • 249
treecoder
  • 9,495
  • 4
    The idea of versions being a single line over time is a factor I hadn't thought about until now, although in retrospect it feels obvious. – jhocking Sep 30 '11 at 12:04
  • 55
    "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
  • 14
    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
  • 1
    @DanRay, what you describe isn't a trust issue. That mechanism is frequent in other systems too. –  Sep 30 '11 at 13:38
  • 2
    @PaulTomblin, if you have a single repository which is the one all releases shipped to the customers are built from automatically, and THAT is backed up, you at least are sure that you have all code shipped to customers. –  Sep 30 '11 at 13:39
  • 2
    @ThorbjørnRavnAndersen, that is correct. However, on 9/11/2001 the company I was working for lost about 1/3rd of our customer base, but our main competitors lost their source tree because they didn't have any off site backups and they were in one of the WTC buildings. We were back up and running in a few days, they were basically out of business. – Paul Tomblin Sep 30 '11 at 13:47
  • @PaulTomblin I am agreeing with you. Just demonstrating an approach that would give the benefit of distribution as well as a production pipeline. Your story proves that extreme paranoia is helpful when designing backup solutions. Perhaps you would like to write it up in a blog entry. –  Sep 30 '11 at 13:49
  • 95
    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
  • 2
    "For example if you're got some critical piece of code that you don't want anyone to access -- you'd probably not want to put it under Git." Can't you do this with Git as well? Centralized repo, everyone has local copies BUT push changes out at the end of the day/after a feature is tested, just like with SVN. DVCS seem to allow the same thing as the non-Distributed, but ALSO give you other options. That would be win-win, no? – Wayne Molina Sep 30 '11 at 14:49
  • 3
    @Wayne, sure. That is one of the most common setups with DVCS in companies. It is also somewhat common in Open Source, except that those without commit access tend to push to their own public repository, and send a pull request. That model is also useful in business. It allows people who are not a project's core developers (such as developers from another team) propose changes, while ensuring that any such changes get reviewed before being added to the main tree. – Kevin Cathcart Sep 30 '11 at 15:12
  • 3
    "subversion does it one way, and nothing else" -> there's no standard way to tag or branch. Branch and tag don't even exist. They are just conventions. All you can do is "copy". Users, by convention may do it one way. Subversion does not. – David Sep 30 '11 at 15:14
  • 7
    It makes me sad to think there are project managers out there that think of developing code as if there is one computer that all the developers have to take turns typing at it sequentially... In real life, commits happen at the "same time", there shouldn't be a race to get to the repository first... – J. Holmes Sep 30 '11 at 15:22
  • 29
    @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
  • 4
    One of the reasons bosses are afraid of git is that it's hard to find any discussion of git that isn't tied to GitHub. They think (or at least, my boss thought when I suggested we change to it) that if you use git, your code will end up on github and exposed to the world. – Paul Tomblin Sep 30 '11 at 16:41
  • 56
    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
  • 3
    svn is a filesystem ? are you sure ? because it is kind of slow for a filesystem. – jokoon Sep 30 '11 at 20:50
  • @DanRay I'd rather have that than my current firm's setup. The codebase is branched for every project, no matter how small. One file, one line change? Project, branch, have it sit in a code-review state and test state, and merge it afterword. I've done more merging in one year here than I have in the five years prior. :\ – corsiKa Sep 30 '11 at 21:24
  • 2
    @DanRay The DVCS manner of implementing that top-down model is with the lietenant model: your boss has control over the primary repository and the rest of you have to issue pull requests, similar to how Linux kernel development is done. When some new code is ready, your boss would pull the changes and then push them up to the top-level origin repository, as he would be the only one with privileges to do so. See: http://git-scm.com/book/en/Distributed-Git-Distributed-Workflows – Dan Lyons Jun 05 '12 at 19:03
  • 10
    WOW, the reasons given in this answer read almost exactly like the spoof Top 10: Why Subversion is better than Git. From a Git perspective, this simply demonstrates you don't understand Git. – WarrenT Aug 30 '12 at 23:34
  • 1
    All I need is a simple system that tells me how my files differ from files in the central repository. A simple system to merge, overwrite, update or commit files individually. All that using an excellent SVN plugin for Eclipse. [quote] Why can't git be used in a centralized manner? Just have one central repository[endquote] Then why Git at all? – Satish Motwani Dec 14 '12 at 10:40
  • 3
    Git can be a central repository too (and usually is under most workflows). Under SVN the code is still copied (and modified) on the local developers machine. SVN is distributed in this regard in that the actual development is not central. SVN is no more secure than git in that regard, just missing the feature to commit locally. The first point is not an advantage of SVN over Git. – mike30 Mar 26 '13 at 19:14
  • Actually, you can straight up check out subtrees with git plumbing commands. Not too useful though. Subtree branching and merging however certainly is. See git-subtree, which is in the contrib/ folder in the official git repo now. – Ericson2314 Jun 23 '13 at 02:13
  • Git is better if you have to detach from the central server. We have to go to remote sites and make changes without internet access and maintain a history. SVN has ways to do that but they are all workarounds. Otherwise, for the group I work with, SVN is simple to use while my peeps have trouble with the complexity of git. – dmh2000 Nov 16 '13 at 16:12
  • 2
    "all (serious) government projects are under central repositories" :( https://github.com/alphagov/ – alexmuller Nov 16 '13 at 17:00
  • 2
    "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."

    Bullshit. Git and Subversion are alike in access control flexibility.

     – mcandre Nov 16 '13 at 18:42
  • 1
    How does the #1 answer not say anything about binary files? – Andy Ray Nov 16 '13 at 20:19
  • 3
    you can actually add an "empty folder" to git with touch path/to/folder/.gitkeep, but, when you do this, you obviously actually don't have an empty folder anymore... – caarlos0 Nov 16 '13 at 21:13
  • 1
    Primary draw of subversion is the central repo. You do not clone the repo locally, only git's equivalent of HEAD. All diffs and such are remote operations so in theory no single developer can just "steal" the entire repository including history. They can only get the tree they have access to. – Dmitriy Likhten Nov 16 '13 at 23:22
  • See: https://svnvsgit.com/ for more info – Erik Aronesty Aug 05 '19 at 16:49
  • subversion is not fragile and generally won't allow you to damage its own history like GIT does. Global revision gives more (temporal) information than hash, specially when the context identifies branch. External links, partial checkouts(I only have partial checkouts of many borderline interesting SVN repos) and a robust merge history that simply works. Cherry picking often already breaks on the first pick out of order. – Marco van de Voort Dec 14 '20 at 18:17
136

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
johannes
  • 3,601
  • 2
  • 27
  • 32
  • 11
    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
  • 3
    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 07 '12 at 06:39
  • 2
    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 08 '12 at 22:03
  • 4
    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 05 '12 at 23:45
  • 19
    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: https://github.com/gitster/git/blob/634392b26275fe5436c0ea131bc89b46476aa4ae/contrib/subtree/git-subtree.txt 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 04:25
  • +1 @James - Our SVN repository is in the terabyte range, due to both the sheer number of projects as subdirectories, and including embedded video and such on our websites. We're not a games company. – Izkata Nov 16 '13 at 16:12
  • I have seen this advantage encourage a bad practice with svn as well. It's more difficult IMO to create new repositories in svn. As a result, people will often just create a new folder in an existing repository, for every project. On the server however, it's not easy to maintain backups of a single repository that has become huge. Also, it's not really possible to clean up or delete old code from a single monolithic svn repo either. The best practice is probably to have a separate repo for anything that can be pulled down in isolation. – Kevin Seifert Jan 08 '16 at 16:14
  • 1
    @Carl: from my reading of that link, there still isn't an easy way to actually clone a subtree - you have to download the whole repo, then sub-select a tree. If the problem is huge sub-directories that you want to avoid, then subtree doesn't help. – naught101 Aug 11 '16 at 04:27
  • @dukeofgaming there are many reasons to like svn over git: https://svnvsgit.com/ – Erik Aronesty Aug 05 '19 at 16:50
  • @Carl subtree seems to do the reverse - it lets you combine multiple repos into one, not check out part of a repo. – user253751 Jul 16 '21 at 09:58
53

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
Wyatt Barnett
  • 20,715
  • 26
    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
  • 12
    @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
  • 4
    @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
  • 25
    @maple_shaft, and sometimes they aren't. http://www.snopes.com/business/genius/spacepen.asp – Peter Taylor Sep 30 '11 at 12:19
  • 3
    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
  • 1
    The reasons given in this answer also read almost exactly like the spoof Top 10: Why Subversion is better than Git. From a Git perspective, this simply demonstrates you don't understand the Git approach as well as you think. – WarrenT Aug 30 '12 at 23:44
  • @WarrenT : funnily enough, I've managed a successful transition to HG with this team. DCVS concepts are not that tricky once you get past the gate I'll admit. But you can't get past the "git is designed to make you feel stupid" angle nor the "git don't quite want to work on windows naively" issue. Finally, it still doesn't handle the "I just want to version some random file trees in a central repo" story at all. – Wyatt Barnett Aug 31 '12 at 00:26
  • Do you not decide which files to add to the index? So why can't you version your random file trees? – WarrenT Sep 01 '12 at 06:29
  • 1
    I'm sure you could figure out a way to handle multiple random filesystem trees in the same project. I also suspect that would take a bit of time and effort. Out of the box SVN lets you check in things at various levels in a central tree. This is a perfect fit for some applications and teams. Which isn't to say that git isn't a perfect fit for other applications and teams. – Wyatt Barnett Sep 01 '12 at 12:29
  • @WyattBarnett: Git isn't designed to make everyone feel stupid. Just CVCS users. Linus Tovald's long-winded and sometimes arrogant explanation of the road to git is quite enlightening, as long as you allow that he's actually attacking a technology, and not a group of people. – naught101 Nov 17 '12 at 00:46
  • @naught101 -- fair point. On the other hand you've got hg which can do pretty much everything git can and doesn't required advanced degrees in command line-fu to get anywhere while also working very seamlessly cross-platform. – Wyatt Barnett Nov 17 '12 at 18:53
  • 1
    I work in a software company that does a lot of small projects - a dozen people would be a large project - with informal code ownership. We get a lot of value out of having a backed up version controlled system to make sure disk crashes don't lose data, and now and then we go back N versions to see when bugs appeared. We don't need more advanced features often enough to learn them. We moved sccs -> SourceSafe -> SVN + tortoiseSVN and at each step we got obvious improvements for little or no cost to learn the new system. The time to learn git might not pay off for us. – mcdowella Nov 17 '13 at 06:33
32
  • 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
Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
Lazy Badger
  • 1,935
  • 23
    Doesn't break your brain? Wanna teach me how to easily merge branches with conflicts in SVN? – WarrenT Aug 30 '12 at 23:17
  • 4
    "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
  • 6
    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
  • 1
    Deleting everything and checking out again will clean unversioned files. – jgmjgm Sep 28 '17 at 17:23
  • I love your last idea, Git broke my brain :'( – Luke May 07 '18 at 16:06
  • @WarrenT a single developer pushing to a single feature branch and pushing a pull req, and then merging to master can and will get conflicts nearly every time if they forget to pull before working again. for simple workflows git can seem insane and thats why it breaks brains. even for many devs.. as long as there's a central master everyone is pull-req to, git comes up with bizarre conflicts for no easily discernible reason. – Erik Aronesty Aug 05 '19 at 16:54
24

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
Dan Ray
  • 9,116
  • Centrality is a matter of myth not fact. Nobody can stop me from changing anything. With a cvcs they can stop me from centrally changing something. Same thing in a dvcs. The word commit in cvcs conflates commit and push. – Warren P Nov 16 '13 at 15:19
  • @JonathanHenson: that is definitely not the only reason Torvalds hates SVN. SVN may be centralized and may be a better CVS but that hardly make it a good software. Torvalds hates CVS / SVN not because they're centralized but because he considers they are pathetically bad software. Whether he's right or not is up to you to decide but seen the immense success of both Linux (and Android) --running on billions of devices-- and Git --which is pretty much taking the world by storm--, I'd think twice before disagreeing with him. The lecture Torvalds gave at Google on Git years ago is amazing. – Cedric Martin Nov 16 '13 at 19:32
  • lol. Your manager is right to be terrified there's no proper backup system in place. Just saying "but its DVCS so someone will have a copy" doesn't fly - I know, when I saw git used at my last place, they literally didn't have any copies of some repos. Mind you, locking can be good for some situations and git fails in this regard - unless you have a magical merge tool for images or other binary files. git only really works for text files. – gbjbaanb Jan 06 '14 at 14:27
23

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
maple_shaft
  • 26,511
  • 11
  • 57
  • 132
  • 3
    Really? Then I'd suggest you have a look at fossil. – Spencer Rathbun Sep 30 '11 at 12:39
  • 8
    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
  • @SpencerRathbun, Thanks! I will have to take a look at that. It is not so much that I love svn as I have a distaste for git. – maple_shaft Sep 30 '11 at 12:46
  • 10
    @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
  • @MarkBooth As stated in the original question, I think it's a matter of wants and needs. At my current workplace, there was no repo before I got there. I needed something that had all, or most, the project tools I wanted wrapped together, was easy to use, kept everything instead of deltas, and would work distributed for teams of 1 or 2 people across multiple machines. – Spencer Rathbun Sep 30 '11 at 14:34
  • @Spencer - Here I was addressing maple-shafts issue with git being too much, as I assumed you were. Incidentally, fossil's distributed bug tracking & wiki sound interesting. Very useful if your customer doesn't have constant net access, but you still want them to submit timely bug reports. (Since this is chatty, I'll delete this when I'm sure it's been read) – Mark Booth Sep 30 '11 at 19:22
  • Git takes "git init" to set up. Done. –  Mar 10 '12 at 13:28
22

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.
Grant Palin
  • 1,721
  • 2
  • 14
  • 28
  • 1
    "commit numbering scheme" is only possible if you have canonical trunks. Otherwise which one gets the major numbering? –  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 07 '13 at 18:57
19

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.

Rook
  • 19,909
  • 2
    How does SVN handle them better? Git considers every file a BLOB. – WarrenT Aug 30 '12 at 22:59
  • 4
    @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
18

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
Andreas Bonini
  • 1,073
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.)

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
Ian
  • 4,603
  • 8
    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
  • Any time you need to do bugfixes in old versions you need branching and merging. –  Mar 10 '12 at 13:31
  • 1
    Why don't people consider the idea that mercurial is easier than svn or git? – Warren P Nov 16 '13 at 15:17
  • I think part of it is that as SVN has until recently not supported branching and merging without a very high cost, it has allowed programmer to stand up more to managers when they wanted to keep changing what someone is working on. A tool has to work within the polities of a company and also helps shapes a companies’ polities. – Ian Nov 16 '13 at 19:08
14

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.

Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
back2dos
  • 30,060
  • git is the more "philosophical" approach to version control. you start to think about semantics of commits, branches, etc. So people who want to use a VCS as a "backup" and distribution tool have a harder time, but git is not much more difficult – wirrbel Nov 16 '13 at 20:06
11

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)
Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
alexandrul
  • 148
8
  • 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.
Tim
  • 272
  • +1 for the authentication issue. Git commits need to be signed, and the signings need to be checked which is difficult. – Christian Nov 16 '13 at 22:03
6

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.

calum_b
  • 109
6

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.

GlenPeterson
  • 14,920
  • 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 07 '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 07 '13 at 20:17
  • @HubertKario - this raises the question, "Should your best programmers be spending their time checking in other people's code?" Actually, I'm so interested in the answer to this question, that I posted it here: http://programmers.stackexchange.com/questions/181817/should-your-best-programmers-have-to-check-everyone-elses-code-into-source-cont – GlenPeterson Jan 07 '13 at 20:41
5

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.

jokoon
  • 2,242
4

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.

William Payne
  • 1,171
2

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.
Peter Mortensen
  • 1,045
  • 2
  • 12
  • 14
Cheung
  • 103
  • 1
    +1 for #1. Compare the SVN vs GIT diagrams here http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/ – s_t_e_v_e Mar 01 '14 at 16:58
1

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.

Sean McMillan
  • 5,074
  • 25
  • 26
-1

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.

Karl Fogel
  • 31
  • 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 00:03
  • Hi, doug. Yes, you can do it for your local repository, but I'm talking about once you've pushed the change elsewhere -- "git commit --amend" doesn't help you much then. In SVN, you can edit the log message on the central server, precisely because there is a concept of a central server. That's what I meant by "impossible by design in decentralized systems". I'll edit my answer to make this clearer. – Karl Fogel Nov 17 '13 at 19:32
  • 1
    I love how "you can fiddle around with history" is allegedly a feature. I'd consider it a bug if it weren't intentional. – cHao Jan 13 '15 at 15:49