Altium Designer uses SVN. Am I right?
Yes.
One problem with Altium, at least before they introduced their "Vaults" (which has its own issues) is that it doesn't like the libraries being on a shared drive. We use a workflow with exactly one company-wide integrated library, which is maintained by the main PCB guy. He keeps various symbol and footprint libraries, and when we need a new part, he creates or finds the symbol and the footprint, adds some company-specific details to the symbol, and then recompiles the libraries into the one integrated library, which is put on a network share.
The problem is that when more than one person is using the library, he can't make changes to it (it borks things badly). So everyone just grabs the latest version of the library and copies it to their local machine. (He sends around an e-mail when changes are made to the library.) It's a manual process, but it's really only a problem when a footprint error is fixed but someone uses the old version of the library before the fix.
So the Altium SVN library takes that "copy to local machine" concept and makes it somewhat better. The library on each user's computer is now a long-term working copy that is checked out of the repository. The librarian makes the change, compiles the library, commits it to the repo, and then the users simply do an $ svn update to grab the latest changes. (And it may even be automated, when you first start Altium it can do that update automatically.)
The vault concept takes this repo thing to a new level, where basically changes to the library are pushed out and made available immediately.
Also, you can keep binary files (of any sort, not just a PCB design or library) in a Subversion repository. Two things to remember.
One is that with text files, Subversion saves differences between revisions when you commit. This saves disk space and makes for speedier network access. If the files are binary, diffs are (for the most part) impossible so each commit sends and saves the entire file.
Two, as has been noted, you can't merge binary files. Why is this important? Say you're working on some code with a friend. You both have working copies checked out on your computers. He makes a change and commits it to the repo. You do an $ svn update to get his changes. What happens is that Subversion silently merges his changes into your working copy. Now what happens if you've made changes to your working copy of the file, but you haven't updated to get his latest changes? When you go to commit, you'll get a conflict warning, and you will have to merge the changes manually. (TortoiseDiff and other tools make this relatively easy.) Fix the conflicts, then commit, and good. With binaries, you don't have the ability to diff, so you can't do a manual merge in case of conflicts. The solution is to obtain a "lock" on the file. Only the working copy with the lock can commit changes back to the repo. A repo can be configured so that certain files automatically have a "needs-lock" property on them, which forces the issue. (TortoiseSVN goes a step further: if you check out a file which requires a lock to commit back, that files is marked as read-only, so you can't even save changes to it.)
In practice, this is less onerous than it seems, and it forces you to talk to your co-developers so everyone knows what is being worked on.
What's so wrong about Git?
Depends on who you ask. Git and Subversion have a different philosophy. The main difference is that with Subversion, there is one repository and users check out what they need from that repository, make the changes, then commit them back. The checkout and commit operations require network access to the repository.
With git, each user makes a clone of the repository. The user can make changes and commit them to the local clone, and at some point he can request that the local changes be committed back to the main repository.
So note that for Subversion, if a user wants to do some experiments and keep track of changes to them, he has to make a branch of the trunk and work on (commit changes to) the branch. When the results are good, the branch needs to be merged back to the trunk. With git, the experiments remain in the user's cloned copy of the repo, so the only time the user interacts with the main repo is when the changes are done. In practice, the result is the same in either case, and it's incumbent on the project maintainers to ensure that commits to the trunk are good.
You can't autosave on a VCS, right?
No, that's not the point of the VCS. You don't want to commit unless you're sure that your work doesn't break someone else's work. You don't even need autosave -- just program your fingers to do Ctrl+S every change. (I am serious.)
That said, some users set up cron jobs (or the equivalent) which will commit changes back to the repo on a regular basis.