What does SVN do better than git?

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.

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 tortiseSVN on windows. TortiseHG 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 config files across dozens of servers without dozens of repositories.

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

• SVN repos are more manageable from manager's and admin's point of view(ACL + auth methods + hotcopy + mirrors + dumps)
• SVN *-hooks are easier to implement and support
• svn:external has more power and flexibility than submodules
• filesystem-based repo trees are easier to use than monolithic repos with logical-only separation
• SVN has more different client-tools
• SVN has third-party usable web-frontend, much better than Git's
• SVN doesn't break your brain

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.

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 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 5 minutes to set up a repository. Git can sometimes be overkill.

When you don’t need to branch and merge, svn (with tortiseSVN on windows) is very easy to understand and use. Git is over 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.)

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 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's no software-enforced Centeral Master Controlling Server To Which We are All Slaves.

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.

Usability. It's not really subversion's merit but rather TortoiseSVN's.. TortoiseGit exists but 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 3rd party tools make such a huge difference.

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

• partial checkouts (like only 3 folders from different depths in the project tree)
• file locking (binary format reports)

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 does no 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 dwo programmers in the team, it made sense for us to also just stick with SVN.

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.

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.

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.

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.

Below is the 2 reason, so that i still stay with SVN.

1. The learning curve , SVN is easier then GIT, even the setup (server or client too), usability , command.
2. Better server package like Subversion edge, visualSVN, uberSVN etc.

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.