22

Possible Duplicates:
Why is git better than Subversion?

I've already read a lot (not enough to get the perfect picture though) about versioning systems, and the obvious conclusion is that GIT is simply the best. Or Bazaar maybe. Or Mercurial. But if so it was, then nobody would be using SVN, but they still do. Why? I myself have no own opinion on what v.c.s. is generally the best yet because of lack of experience with them. Could you share your thoughts?

Community
  • 1
  • 1
Ivan
  • 59,167
  • 87
  • 235
  • 370
  • That *"GIT is simply the best"* does not look like an obvious conclusion at all. It is more like a heavily biased opinion. And you contradict yourself then saying *"I myself have no own opinion on what v.c.s. is generally the best"* . WTF are you trying to say anyway? – Juliano Jul 09 '10 at 18:01
  • 1
    Check out [Why is GIT better than Subversion?](http://stackoverflow.com/questions/871/why-is-git-better-than-subversion). It has almost 200 votes. – DOK Jul 09 '10 at 18:01
  • 10
    @Juliano: Go easy, man. I think what he is saying, is that based on what he's read in the literature, it sounds like Git is a slam dunk, but that he has no practical experience on which to formulate his own opinion. – Dan Moulding Jul 09 '10 at 18:08
  • 1
    The CVCS model is easier to grasp than a DVCS one. See http://stackoverflow.com/questions/2704996/describe-your-workflow-of-using-version-control-vcs-or-dvcs: DVCS (Distributed VCS) will add a new dimension (publication, and not just branching: http://stackoverflow.com/questions/3032007/code-promotion-with-git/3032126#3032126) – VonC Jul 09 '10 at 18:16
  • 1
    This isn't a duplicate of [Why is git better than Subversion?](http://stackoverflow.com/questions/871/why-is-git-better-than-subversion). This is the inverse question. – Max Nanasy Feb 08 '15 at 07:31
  • The only real reason where SVN wins is http://blog.assembla.com/AssemblaBlog/tabid/12618/bid/7437/Why-Subversion-does-not-suck.aspx – Pacerier Mar 25 '15 at 17:34

8 Answers8

36

I'm currently maintaining a version control service for a U.S. research institution. We're not only supporting SVN in addition to Git and Mercurial, but also CVS.

SVN's "killer feature" among our users is narrow clones. You can make a checkout of just one subdirectory deep in a heirarchy, download only the files related to that directory, and still be able to make commits. Git very recently gave a similar, but not quite as useful variation on this feature called sparse checkouts (see also Sparse checkout in Git 1.7.0?). This lets you filter your working tree, but still forces you to download the entire history of the entire project, which can be prohibitive even when large binaries aren't involved. Mind you, disk is cheap, and if you absorb the hit of the initial clone in advance subsequent pulls are quick enough, but this doesn't help people that went on a trip before they realized they needed to clone, and in any case even Git's sparse checkouts won't let you start your working tree five levels down, so it looks a bit ugly.

In addition, users find authz files easier to write than Git commit hooks, are more comfortable with the SVN syntax and methodology than any DVCS, and perhaps most importantly of all, already have many thousands of commits worth of history in SVN. Experiments in migrating large Subversion repositories to Git or Mercurial have provided mixed results, and these are scientists trying to get work done on their own projects, not donating their time to development of a DVCS.

CVS still has a following for a similar reason. Imagine, as a Git user, having sparse checkouts that also allow you to arbitrarily remap where files in the branch show up in your working tree, using a format that is versioned along with the repository and is distributed with every usual pull, that allows you to write definitions that can have groups that can include other groups, and that only pulls down the files necessary for filesystem placement on a clone. That's straightforward in CVS modules, and impossible in every DVCS. For all the sins of CVS (and believe me, we're quite aware of them, and go out of our way to discourage new CVS projects unless they absolutely can't live without modules), it's impossible to convince a group using that feature to migrate to another version control system.

DVCS software has brought some awesome innovations, but they're also missing things that some developers take for granted. Make sure you know in advance what your requirements are before choosing one.

Community
  • 1
  • 1
Zed
  • 3,287
  • 3
  • 17
  • 20
  • 1
    SVN "narrow clones" is called "sparse directories", or occasionally as "shallow checkouts". Its an awesome feature. – gbjbaanb Jul 11 '10 at 14:47
  • 2
    Migrating thousands of commits from system A to system B is always difficult. This is an argument against switching systems, not an argument against DVCS. – JesperE Sep 03 '12 at 08:38
  • 7
    Sure, but nobody asked for an argument against DVCS. The question was, why would you use SVN, and a perfectly valid reason is that there's a lot of SVN history. – Zed Sep 04 '12 at 15:11
  • 1
    +1 for mentioning sparse checkouts. That was new to me. Thank you – fkl Nov 16 '13 at 19:30
  • 1
    not only that, but svn allows folder based update, folder based cleanup, commit without update, keep a clean linear history and is easier to understand. on top of my head. – v.oddou May 31 '16 at 05:15
17

Talking about the company I work for — the biggest reason for using SVN is being able to keep huge, proprietary format, binary files under version control. Specifically, libraries of thousands of CAD files. In this instance, it does make sense to have the VCS be file-based like SVN is, rather than textual-information-based like Git.

Putting aside whether or not you can do shallow "checkouts" with Git, or how well it stores binary data, the fact is that it's designed to track lines of textual information floating around a tree of source code. As well as it does this, that model is not suited to tracking libraries of binary data.

Honestly though, that's about the only solid reason I would recommend it :P

detly
  • 26,649
  • 13
  • 85
  • 142
  • This is a good justification. Subversion also has shallow checkouts. Critical to large binary repositories. – Matt Joiner Nov 19 '10 at 16:15
  • 1
    This is actually the only good technical reason that makes a LOT of Game Developers stay out of Git and Mercurial at least for art files. Indeed, working with art files imply huge data which still need to be managed in a similar way than code source, and it's simpler to have everything together. Mercurial tried to fix this problem with the largefile extension that is now official and provided with hg, but it don't really solve the problem in the end and makes organization complicated. – Klaim Apr 10 '13 at 16:02
  • 2
    Hi, as of today (2015) do you still agree that it is a good option for image & large files? – Draconar Mar 23 '15 at 21:36
  • 1
    @Draconar I've actually moved on from this company and no longer use SVN that much. Having said that, I don't see any reason why this would be different now. Unless Git/Mercurial have altered their model to cope with binary files, SVN's single-revision-checkout/binary-diff model seems to be better suited. – detly Mar 23 '15 at 21:55
  • @detly, I think Git has binary extensions already. – Pacerier Mar 25 '15 at 17:37
  • serious games companies use Perforce. – v.oddou May 31 '16 at 05:16
11

SVN is established and mature, with equally mature tooling.

sylvanaar
  • 7,862
  • 34
  • 58
10

Aside from the other things people are mentioning, (large quantities of binary data, mature, stable, etc) is that svn is built on a classic hierarchical model that is fundamentally different from patch/change-based revisions.

Our company made the decision to stay with SVN because this model fit the way that we handle our release cycle and branching. We see the direct progression of versions as a boon, not a bane. Updates are pushed to a centralized repository, and certain revisions considered "stable" are checked out to a live environment. At any time, it is instantly clear what the state of each environment is to all involved. (yes, this is possible with git.) Even the management who know nothing about revision control or software development can say: "We liked how you had it when it was at version 2547".

On the other hand, I should mention that I use darcs and git for projects that I and my friends and co-FOSS'ers work on together, as the distributed, patch-based model works for us. We can ad-hoc move through the timeline of the project and cherry-pick all kinds of changes.

Really the advantage of SVN, my company, is its strong hierarchy and accessibility to non-programmers who are already familiar with concepts of "logging in" and "downloading".

sleepynate
  • 7,296
  • 2
  • 24
  • 38
6

Subversion has an advantage when a repository contains lots of binary data, which don't delta-compress well. A Subversion checkout grabs the head only, but git clones the entire history, which can weigh in at multiple gigabytes. Yes, this is nice for airplane mode, but fetching the initial clone can take hours.

Greg Bacon
  • 121,231
  • 29
  • 179
  • 236
  • 2
    If you don't want to fetch all the previous history of a git repository, you can do a shallow clone (with `git clone --depth=$depth`). You can't use this incomplete clone for further cloning, pushing/pulling, etc., but it's enough to be able to make edits with local revision control and send these commits as patches for upstream inclusion. – Vineet Jul 09 '10 at 18:42
  • 7
    The inability to push or pull makes that feature nearly worthless to all the environments I've worked in. Nobody wants to send patches by hand, or deal with trying to collate them all. – Zed Jul 09 '10 at 18:52
  • @Zed, It doesn't need to be done by hand. Couldn't there be a tool to do it? – Pacerier Mar 25 '15 at 17:41
5

People are still using Subversion because it's designed using the first paradigm to come for version control systems (centralized). Switching to distributed (and change-based instead of version-based) can take some time to get accustomed to (as you can see in Joel's experience), and so many teams decide not to use it due to resistance to change.

Mercurial tooling is quite mature, comparable to SVN in my opinion.

Kenji Kina
  • 2,352
  • 3
  • 20
  • 37
  • 3
    Subversion's paradigm was not the first one to come. This paradigm was inherited from CVS, which implemented the client-server model. Before that there was the SCCS and RCS local shared repository model. – Juliano Jul 09 '10 at 18:04
  • 3
    That paradigm is still centralized. – Kenji Kina Jul 09 '10 at 19:15
  • 2
    @Juliano, SVN and CVS follow the same paradigm, so CVS's can't come before SVN's... Centralized VC cannot come before centralized VC... – tobyodavies Feb 07 '11 at 02:12
  • Though to be fair, RCS/SCS's paradigm of lock, modify, unlock came before checkout, merge, checkin... Used in CVS/SVN, so even though Centalized, Merging VC is used in both, they are still not really first, so you are right on that front... – tobyodavies Feb 07 '11 at 02:23
3

While svn is established/mature, I have to admit, Kenji Kina is right: it's living in the past with a version control model that is outdated. I've only used svn, but after reading/watching Linus and Joel talk about DVCS, it sounds like a brilliant idea. I think Perforce does something similar.

This doesn't mean svn is bad (it works rather well!), but it is easier to manage your code and have more frequent commits with a DVCS. Because if you break something, its easy to undo. If you branch, its easy to merge. In general, they fixed a lot of the major headaches most have with Subversion.

If you've never used another version control system before, and are cool with deploying it yourself, and write code (and not documents or pictures or things that you don't need textual stuff/diffing for), do yourself a favor and look into DVCS. Then you won't need to be re-educated.

J. Polfer
  • 11,281
  • 9
  • 52
  • 81
  • it sounds a brilliant idea... I've seen so much marketing material for truly poor products, I never believe the hype anymore - only after I've actually used something and understood its weak points. DVCS are good, but solve different problems to CVCS and are not always so suitable. – gbjbaanb Jul 11 '10 at 14:50
  • @gbjbaanb - That can be true. I just have VCS-envy. :) lol – J. Polfer Jul 31 '10 at 16:42
-1

Go through this http://www.stevestreeting.com/2009/09/28/early-stage-gitmercurialbazaar-evaluation-thoughts/

gsoni
  • 1,068
  • 14
  • 24