I am currently deep into Git before ever mastering SVN. Its my first serious source control management system learning experience.
I wonder about the opportunity-cost of not learning (or even de-learning what little I learned about) SVN. Is there something that I need to watch out for?
Are there things that are just not doable or prohibitively hard in Git as compared to SVN?
Git can not svn lock documents, so that someone could prevent others from editing a non-auto-mergeable entity (such as Word or Excel file).
Git can't check out a subtree and use that as though it was a complete repository.
For example, with Subversion you can check out the directory "trunk" and use that as if it was a repository. You can also check out "branches/feature1" and use that. With Git it's only possible to check out the root directory (although with recent versions you can do a sparse checkout which doesn't download all files, you still have to check out the root though). In Git you would use branches instead of checking out subtrees.
I think that one of the few use cases where you might prefer to use Subversion instead of git is if you're trying to manage a very large repository of binary media where people mostly only want the most recent version. e.g. say you're developing a game, and the artists need to track revisions of all the artwork, but the entire history of the repository would be huge (100s of gigabytes)
To be fair to git, this is a use case that's very far from what it was designed to do (manage source code repositories) and there are various workarounds or extensions that might help if you really want to use git for that, e.g.:
... but it's still an area where one would probably prefer SVN. There's an brief presentation on this subject from a GitTogether a couple of years ago.
Git can't store empty directories. Arguably, this is an advantage, but it is one thing that git can't do but svn can.
This Wiki has a nice comparison: https://git.wiki.kernel.org/index.php/GitSvnComparison
Summarized
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.
Found this and agree with it. Again the newbees are pretty agro when you touch git. I cannot trust git or github until a few more security changes like going one step beyond the hackable ssh keys.
For us the most important feature of SVN ist the ability to repositoy-wide lock files. Since we work with binyary and unmergeable CAD files the merge-based workflow of any DVCS doesn't work here.
You cannot restrict read access to a part of the repo (i.e. only allow reading of certain files, or only part of the history). This is a direct consequence of the fact that you can only clone a complete repository (as explained in Theo's and Mark Longair's answer). If you want different levels of read access for different files, you must put them into different repositories (which can be included as submodules into the main repo).
Note that you can restrict write access to a repo based on many criteria (path, file name, history modification). You need to use special software in addition to git to do this (such as gitosis ), but that is similar with Subversion.
In practice the above is not usually a problem, because in Git the idea is that a repository contains files that are typically used together (such as the source code of one program or project) - so usually restricting read access to a part is pointless, because you need all the files to build/work with the project. However, if you put many loosely related things into one git repo, this may bite you.
I would say that you can do almost everything that matters in git and even more than subversion enables you to do. That should not be your worry. However both are popular and deserve your attention especially if you are in opensource programming.
I would however consider git to be harder to learn but once you got the hang of it people are usually addicted and find other SCMs inferior. The distributed support for git is excellent (there are others as well, but git is probably the most widespread) which happens to be useful for a bunch of other tasks than managing source code alone. git can be considered a ZIP-utility on steroids and can be quickly deployed to track general filesystem changes and to replicate changes between hosts in an efficient manner.
On windows there are some issues with git:
But I would consider things that git has and SVN does not. Not having excplicit support for branches in SVN is a major issue - the git implementation is very nice and lets you branch without even thinking of branches. Being able to work offline is a major treat as well.
Two more things svn can do and I miss in git:
With Git's distributed nature, there is no single place (server) where you/sysadmin can backup the entire code base. Each node must take their own backups or merge daily to a node which takes daily backups.
