What does SVN do better than Git? [closed]

Question

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

• 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

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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.

Answer 9

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.

Answer 10

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.)

Answer 11

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.

Answer 12

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)

Answer 13

• 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.

Answer 14

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.

Answer 15

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.

Answer 16

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.

Answer 17

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.

Answer 18

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.

Answer 19

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.

Answer 20

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.